arechen/EapilSkillMarket
1
1 Fork 1
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Sync third-party and MCP marketplace plugins

Browse Source 
Constraint: Public skills are published only by explicit administrator action unless they are tracked third-party market sources.
Confidence: high
Scope-risk: narrow
Directive: Keep private/internal skills out of the public marketplace and preserve normal incremental market Git history.
Tested: Marketplace validation passed.
This commit is contained in:
KeyInfo Bot committed 2026-10-21 14:51:10 +08:00
1 parent 6056566972
commit 64087ca43c
126 files changed
+9835 -7317
Download Patch File Download Diff File Expand all files Collapse all files

No files matched your search

config/external-sources.json
+5 -17
View File
@@ -647,7 +647,7 @@
"interface": { "interface": {
"displayName": "Taste Skill", "displayName": "Taste Skill",
"shortDescription": "反模板化前端设计、重设计和图像参考生成 skill 集合。", "shortDescription": "反模板化前端设计、重设计和图像参考生成 skill 集合。",
"longDescription": "Taste Skill 提供 design-taste-frontend、gpt-taste、image-to-code、redesign、minimalist、brutalist、soft、stitch、output enforcement，以及 Web、移动端和 brandkit 图像生成等多个 skills，用于让 AI Agent 产出更有设计判断、更少模板感的前端界面和视觉参考。", "longDescription": "Taste Skill 提供反模板化前端设计、重设计、图像参考生成和高质量输出约束工作流，用于让 AI Agent 产出更有设计判断、更少模板感的前端界面。",
"developerName": "Leonxlnx", "developerName": "Leonxlnx",
"category": "Creativity", "category": "Creativity",
"capabilities": [ "capabilities": [
@@ -665,19 +665,7 @@
} }
}, },
"skillDescriptions": { "skillDescriptions": {
"brandkit": "用于生成高端品牌指南、Logo 系统、视觉世界和品牌应用参考图的图像生成 skill。", "taste-skill": "用于落地页、作品集和重设计任务的默认 anti-slop 前端设计 skill。"
"brutalist-skill": "用于生成工业粗野主义、瑞士排版和战术终端风格界面的前端设计 skill。",
"gpt-tasteskill": "面向 GPT/Codex 的高强度前端设计和 GSAP 动效规则 skill。",
"image-to-code-skill": "用于先生成网站设计参考图、再分析并实现前端代码的 image-to-code 工作流。",
"imagegen-frontend-mobile": "用于生成高质量移动端 App 屏幕和流程参考图的图像生成 skill。",
"imagegen-frontend-web": "用于生成高质量网站、落地页和多区块页面参考图的图像生成 skill。",
"minimalist-skill": "用于生成克制、编辑感、类 Notion/Linear 的极简产品界面。",
"output-skill": "用于约束 AI 完整输出代码，避免占位注释、省略实现和半成品交付。",
"redesign-skill": "用于审计并升级已有项目界面，修复布局、层级、间距和通用 AI 风格问题。",
"soft-skill": "用于生成高端、柔和、留白充足且具有精致动效的视觉设计。",
"stitch-skill": "用于生成 Google Stitch 兼容的 DESIGN.md 语义设计系统规则。",
"taste-skill": "用于落地页、作品集和重设计任务的默认 anti-slop 前端设计 skill。",
"taste-skill-v1": "Taste Skill v1 兼容版本，用于需要保持原始行为的项目。"
} }
}, },
{ {
@@ -1239,9 +1227,9 @@
"adapter": "claude-skill", "adapter": "claude-skill",
"pluginName": "artemis-automation", "pluginName": "artemis-automation",
"category": "Developer Tools", "category": "Developer Tools",
"skillPath": "skills/artemis-automation", "skillPath": "skills/artemis-use",
"sparseCheckout": [ "sparseCheckout": [
"skills/artemis-automation", "skills/artemis-use",
"LICENSE" "LICENSE"
], ],
"brandColor": "#2563EB", "brandColor": "#2563EB",
@@ -1251,7 +1239,7 @@
"name": "chenmingxuan", "name": "chenmingxuan",
"url": "https://git.playones.com/chenmingxuan" "url": "https://git.playones.com/chenmingxuan"
}, },
"homepage": "https://git.playones.com/chenmingxuan/Artemis-Eapil/src/branch/main/skills/artemis-automation", "homepage": "https://git.playones.com/chenmingxuan/Artemis-Eapil/src/branch/main/skills/artemis-use",
"repository": "https://git.playones.com/chenmingxuan/Artemis-Eapil.git", "repository": "https://git.playones.com/chenmingxuan/Artemis-Eapil.git",
"license": "Apache-2.0", "license": "Apache-2.0",
"keywords": [ "keywords": [
config/external-sources.lock.json
+26 -26
View File
@@ -42,8 +42,8 @@
"repo": "https://github.com/vercel-labs/skills.git", "repo": "https://github.com/vercel-labs/skills.git",
"ref": "main", "ref": "main",
"adapter": "claude-skill", "adapter": "claude-skill",
"commit": "13e4063a1cf913f5606d57d42ab83a86f5001e04", "commit": "a80e4c9d12d607631249d4d7d059f835d4b2f13a",
"syncedAt": "2026-10-10T16:00:00Z" "syncedAt": "2026-10-21T06:48:34Z"
}, },
{ {
"id": "generate-agents-md", "id": "generate-agents-md",
@@ -94,10 +94,10 @@
"id": "dingtalk-workspace", "id": "dingtalk-workspace",
"pluginName": "dingtalk-workspace", "pluginName": "dingtalk-workspace",
"repo": "https://github.com/DingTalk-Real-AI/dingtalk-workspace-cli.git", "repo": "https://github.com/DingTalk-Real-AI/dingtalk-workspace-cli.git",
"ref": "v1.0.64", "ref": "v1.0.65",
"adapter": "skill-collection", "adapter": "skill-collection",
"commit": "e2c0cdf97e016ee76687d9c26986c23a26a84738", "commit": "92c4f8c355c749ec470c68f998d862a00d7d1709",
"syncedAt": "2026-10-14T16:00:00Z" "syncedAt": "2026-10-21T06:48:34Z"
}, },
{ {
"id": "ui-ux-pro-max", "id": "ui-ux-pro-max",
@@ -114,8 +114,8 @@
"repo": "https://github.com/JuliusBrussee/caveman.git", "repo": "https://github.com/JuliusBrussee/caveman.git",
"ref": "main", "ref": "main",
"adapter": "codex-plugin", "adapter": "codex-plugin",
"commit": "81958ad82f2e2da4417778f81f8a3c838d81b798", "commit": "bad48a0e1df55e05e3f52249afa35ecc1909ee76",
"syncedAt": "2026-10-17T16:00:00Z" "syncedAt": "2026-10-21T06:48:34Z"
}, },
{ {
"id": "taste-skill", "id": "taste-skill",
@@ -123,8 +123,8 @@
"repo": "https://github.com/Leonxlnx/taste-skill.git", "repo": "https://github.com/Leonxlnx/taste-skill.git",
"ref": "main", "ref": "main",
"adapter": "skill-collection", "adapter": "skill-collection",
"commit": "f624f37a8c650b9cc550253104925efe4c8de246", "commit": "6010f91a9935f1c167dfc500fb1a475681892e6b",
"syncedAt": "2026-10-14T16:00:00Z" "syncedAt": "2026-10-21T06:48:34Z"
}, },
{ {
"id": "shadcn", "id": "shadcn",
@@ -132,8 +132,8 @@
"repo": "https://github.com/shadcn-ui/ui.git", "repo": "https://github.com/shadcn-ui/ui.git",
"ref": "main", "ref": "main",
"adapter": "claude-skill", "adapter": "claude-skill",
"commit": "d2fba50ee5b9113008b5bb908563527b7efd2f27", "commit": "ba1503c64472b82256d9de95e2e62c5901a38e8b",
"syncedAt": "2026-10-17T16:00:00Z" "syncedAt": "2026-10-21T06:48:34Z"
}, },
{ {
"id": "frontend-slides", "id": "frontend-slides",
@@ -168,8 +168,8 @@
"repo": "https://github.com/hugohe3/ppt-master.git", "repo": "https://github.com/hugohe3/ppt-master.git",
"ref": "main", "ref": "main",
"adapter": "claude-skill", "adapter": "claude-skill",
"commit": "b113d23720260c411ee47b2b05a73615f954deeb", "commit": "cc8b722a24e9fb540e67c2d58a9ea3da534cd682",
"syncedAt": "2026-10-17T16:00:00Z" "syncedAt": "2026-10-21T06:48:34Z"
}, },
{ {
"id": "grill-me", "id": "grill-me",
@@ -177,8 +177,8 @@
"repo": "https://github.com/mattpocock/skills.git", "repo": "https://github.com/mattpocock/skills.git",
"ref": "main", "ref": "main",
"adapter": "skill-collection", "adapter": "skill-collection",
"commit": "49dd158d1076134a641b33efb035946536778336", "commit": "5beb35b040e3de97e54fa9e386d7e42d15c295c2",
"syncedAt": "2026-10-09T16:00:00Z" "syncedAt": "2026-10-21T06:48:34Z"
}, },
{ {
"id": "updating-gitea-repositories", "id": "updating-gitea-repositories",
@@ -193,10 +193,10 @@
"id": "etunel-role-collaboration", "id": "etunel-role-collaboration",
"pluginName": "etunel-role-collaboration", "pluginName": "etunel-role-collaboration",
"repo": "https://git.playones.com/chenmingxuan/EP-Hub-Skill.git", "repo": "https://git.playones.com/chenmingxuan/EP-Hub-Skill.git",
"ref": "v2.0.0", "ref": "v2.1.0",
"adapter": "claude-skill", "adapter": "claude-skill",
"commit": "98541d682bf2ff4b4127eee19eeb76a3b66ada47", "commit": "075837d51f5816ad42154f84683ff6b5605654fc",
"syncedAt": "2026-10-12T04:59:58Z" "syncedAt": "2026-10-21T06:48:34Z"
}, },
{ {
"id": "hardware-development", "id": "hardware-development",
@@ -211,19 +211,19 @@
"id": "artemis-case-prep", "id": "artemis-case-prep",
"pluginName": "artemis-case-prep", "pluginName": "artemis-case-prep",
"repo": "https://git.playones.com/hejunxian/artemis-case-prep.git", "repo": "https://git.playones.com/hejunxian/artemis-case-prep.git",
"ref": "v1.1.0", "ref": "v1.2.0",
"adapter": "claude-skill", "adapter": "claude-skill",
"commit": "e1e094513f4b9360231022f6d18a0ebc6a04dc7d", "commit": "f0b9fc6efac82f825ffc27051a04d47f22ba5362",
"syncedAt": "2026-09-28T10:12:45Z" "syncedAt": "2026-10-21T06:48:34Z"
}, },
{ {
"id": "artemis-automation", "id": "artemis-automation",
"pluginName": "artemis-automation", "pluginName": "artemis-automation",
"repo": "https://git.playones.com/chenmingxuan/Artemis-Eapil.git", "repo": "https://git.playones.com/chenmingxuan/Artemis-Eapil.git",
"ref": "v1.5.2", "ref": "v2.0.0",
"adapter": "claude-skill", "adapter": "claude-skill",
"commit": "bdc75d0c657c5c2707b4c6e352eed6a1f5c14fff", "commit": "973ccae679b082f9ac5df85b6c2ea272ba29b828",
"syncedAt": "2026-10-12T15:59:59Z" "syncedAt": "2026-10-21T06:48:34Z"
}, },
{ {
"id": "embedded-app-pc-debug", "id": "embedded-app-pc-debug",
@@ -258,8 +258,8 @@
"repo": "https://github.com/vercel/next.js.git", "repo": "https://github.com/vercel/next.js.git",
"ref": "canary", "ref": "canary",
"adapter": "skill-collection", "adapter": "skill-collection",
"commit": "e2e7393c1f8449759aa1ae502b64fd7e946fbf37", "commit": "72895219d44df111ee6ac81e4eac10d81a5e5cbf",
"syncedAt": "2026-10-17T16:00:00Z" "syncedAt": "2026-10-21T06:48:34Z"
}, },
{ {
"id": "shuorenhua", "id": "shuorenhua",
plugins/codex/plugins/artemis-automation/.codex-plugin/plugin.json
+2 -2
View File
@@ -1,12 +1,12 @@
{ {
"name": "artemis-automation", "name": "artemis-automation",
"version": "1.5.2", "version": "2.0.0",
"description": "使用 ARTEMIS MCP 完成 Android 自动化测试、批量执行、失败诊断、历史检索和报告交付。", "description": "使用 ARTEMIS MCP 完成 Android 自动化测试、批量执行、失败诊断、历史检索和报告交付。",
"author": { "author": {
"name": "chenmingxuan", "name": "chenmingxuan",
"url": "https://git.playones.com/chenmingxuan" "url": "https://git.playones.com/chenmingxuan"
}, },
"homepage": "https://git.playones.com/chenmingxuan/Artemis-Eapil/src/branch/main/skills/artemis-automation", "homepage": "https://git.playones.com/chenmingxuan/Artemis-Eapil/src/branch/main/skills/artemis-use",
"repository": "https://git.playones.com/chenmingxuan/Artemis-Eapil.git", "repository": "https://git.playones.com/chenmingxuan/Artemis-Eapil.git",
"license": "Apache-2.0", "license": "Apache-2.0",
"keywords": [ "keywords": [
plugins/codex/plugins/artemis-automation/THIRD_PARTY_SOURCE.json
+4 -4
View File
@@ -1,9 +1,9 @@
{ {
"sourceId": "artemis-automation", "sourceId": "artemis-automation",
"repo": "https://git.playones.com/chenmingxuan/Artemis-Eapil.git", "repo": "https://git.playones.com/chenmingxuan/Artemis-Eapil.git",
"ref": "v1.5.2", "ref": "v2.0.0",
"commit": "bdc75d0c657c5c2707b4c6e352eed6a1f5c14fff", "commit": "973ccae679b082f9ac5df85b6c2ea272ba29b828",
"adapter": "claude-skill", "adapter": "claude-skill",
"sourcePath": "skills/artemis-automation", "sourcePath": "skills/artemis-use",
"syncedAt": "2026-10-12T15:59:59Z" "syncedAt": "2026-10-21T06:48:34Z"
} }
plugins/codex/plugins/artemis-automation/skills/artemis-automation/SKILL.md
-49
View File
@@ -1,49 +0,0 @@
---
name: artemis-automation
description: 使用 ARTEMIS MCP 在 Android 真机或模拟器上完成自然语言测试、批量用例执行、失败诊断、历史检索与 Word/Excel 报告交付。适用于用户希望 AI 操作或测试 Android 应用、导入测试用例或分析 ARTEMIS 执行结果。
---
# ARTEMIS 自动化
当前仅提供 Codex MCP 配置安装与更新：`uv run artemis mcp --install codex`；模板使用 `uv run artemis mcp --generate-config codex` 查看。启动日志会打印实际 Codex 配置路径，更新后重载 MCP。
Windows 启动脚本只提示源码更新。升级使用 `update.bat`（国内镜像 `update-cn.bat`），会终止该项目的 ARTEMIS 服务、MCP 和运行任务；仅在用户授权升级或终止任务后执行，先告知任务将中断。升级会同步依赖、网页及 Codex MCP，保留配置和历史；完成后启动 ARTEMIS 并重载 Codex MCP。不要通过启动脚本拉取源码或强行覆盖本地修改。
使用项目提供的 MCP 工具操作 Android。报告由 ARTEMIS 自己生成，不要求宿主 AI 具备 Codex 私有工具、Word 或 Excel 插件。该 Skill 不提供桌面/浏览器自动化，也不提供历史动作脚本回放。
## 从需求到执行
1. 明确目标、预期结果、目标应用和必要前置条件。用户已授权执行且信息足够时直接开展，不逐步索要批准；缺少会改变业务操作的条件时再询问。用例起点按实际需求安排，不默认清数据、重装、重启应用或退出登录。
2. 用 `mobile_workspace` 查看设备和队列。沿用用户已指定的设备；多台可用设备且没有选择时先询问，不擅自挑选实体手机。任务参数显式传入 `device_serial`。同设备串行，不同设备可并行；本 Skill 不要求创建其他 AI 子代理。
3. 首次使用、工具出错、任务拒绝或设备异常，先 `mobile_diagnose`。按 `next_steps` 的依赖顺序处理；`attempt_fix=true` 可尝试工具自带修复。只有凭据相关故障才使用 `verify_credentials=true`，观察异常才使用 `probe_device=true`。不要盲目重发任务。MCP 不可用时在项目目录运行 `uv run artemis doctor` 并检查宿主 MCP 日志。
4. 选择执行模式：Flash 适合路径明确的界面操作；Pro 适合动态分支、持续计划、ADB/日志诊断或需要 Checker 明确校验的任务。**`mobile_run_task.model` 的 `flash`/`pro` 是执行模式，不是 API 模型名称**。步数长不自动等于需要 Pro；视频能力只有显式启用后才可用。
5. 单任务用 `mobile_run_task`；批量任务用 `mobile_batch`，读 [批量任务与交付](references/batches.md)。AI 可直接提交结构化用例，不必先创建 Excel。用户提供 Excel 时先 `mobile_task_file(action="preview", path=绝对路径)`，修正所有行错误后提交。提示词列原样作为目标，前置约束列只作元数据。
6. 单任务返回 `trace_id` 后，用 `mobile_manage_task(action="status", trace_id=...)` 跟踪；网页任务也可用其任务编号。批次用 `mobile_batch(action="get", batch_id=...)`。需要人工补充时用 `pause`，其返回的 `pausing` 只表示请求已接收；轮询到 `task_paused` 才表示设备已释放。`inject_instruction` 会立即取消进行中的模型回复或只读诊断并重新观察手机，已开始的设备动作会先安全结束；暂停中提交则恢复。`guidance_history` 的 `pending/consumed` 区分提交和执行端领取，无新指导用 `resume`。恢复进入设备 FIFO 队尾并重新观察手机状态。尊重工具建议的等待周期，避免连续高频轮询；停滞或失败先诊断，不把同一业务任务自动重提。
## 结果、证据与交付
- 执行状态与业务判定分开：`completed` 只说明执行结束，不等于测试通过。Flash 和 Pro 默认根据任务提示词、用户指导、执行结论和实际证据进行只读终检，不需要另填预期结果。读取 `test_result.status`（`passed` 通过、`failed` 不通过、`inconclusive` 未验证、`blocked` 阻塞）、`reason` 与 `evidence`，结合验证摘要和 `mobile_inspect_trace` 的步骤/截图交付结果。执行失败不能直接认定产品缺陷；已确认的断言失败不得被后续成功覆盖。终检关闭、出错或证据不足时不得宣称通过。
- 用 `mobile_export_report(session_id=...)` 获取单任务报告；`formats=["screenshots"]` 获取排序截图，`["video"]` 获取保存的录屏分段，`["all"]` 获取 Word、Excel 和所有可用资料的 ZIP。批次传 `batch_id` 获取汇总、各项任务报告、步骤截图及已有录屏的 ZIP。未指定格式时使用保存的 Word/Excel 偏好。执行中的导出只是当前快照。
- 工具返回 MCP 主机上的绝对文件路径和下载 URL。向用户交付真实生成的文件链接，并说明完成、失败、未验证、跳过数量及重要限制。不要只说“报告已生成”而不交付文件。
- 用 `mobile_search_history` 按名称、目标、编号或标签搜索全部历史；日期先按用户时区转换为 Unix 秒，`start` 含边界、`end` 不含边界。按返回的 `total/page/size` 翻页，不能把第一页当作全部历史。
- `mobile_inspect_trace` 是只读步骤证据查看；其中历史上下文的 replay 术语不表示重新执行设备动作。
## 配置和恢复边界
- 本机常见模拟器在设备刷新、启动及重启 ADB 后自动发现并连接，不必猜固定端口。USB 与 Android SDK 模拟器由 ADB 原生发现。首次连接其他 TCP 设备/无线手机时，在网页“无线 ADB”填写实际地址和端口，成功后程序保存地址并自动重连；无线调试的配对和授权仍由用户完成，端口变化后需重新连接。远程/转发 ADB 不执行本机发现。用 `mobile_workspace` 或 `mobile_diagnose` 检查自动连接结果；多设备时仍先确认用户要测试哪台。默认开关及扫描预算可由 `mobile_config(section="capabilities")` 的 `adb_auto_connect`、`adb_discovery_interval_seconds`（10）、`adb_discovery_timeout_seconds`（5）配置，修改全局默认需要用户授权。
- `mobile_config` 读取非敏感设置。只有用户明确要求保存或修改默认配置时，才传 `changes` 与 `persist_defaults=true`；这些设置影响后续任务，不能为一次临时需求擅自改变以后所有任务。
- 模型名称支持预设 `gpt-5.6-luna`、`gpt-6-luna`、`mimo-v2.6-flash`、`mimo-v2.6-pro` 和自定义名称，取决于用户配置的 Responses 网关。思考强度最高支持 `max`，默认 `high`、单次请求 300 秒、失败后最多重试 5 次；普通错误每次等待 10 秒，429 每次等待 60 秒。首选模型连续 3 次未形成有效工具调用时，当前步骤改用 `gpt-6-luna`（high），兜底最多再尝试 3 次；下一步恢复首选模型。默认关闭视频分析与录屏。不根据模型名称猜测网关能力。
- 强度选 `default` 表示不发送该参数，和 `none`（显式要求关闭）不同。接口拒绝强度参数时明确呈现失败，先询问用户是否改用 `default`，不能静默降级或换模型。
- API Key 只通过网页或 `.env` 配置。不要请求用户把 key 发到聊天中，不读取/回显已有 key。保存后新任务生效；直接编辑环境文件后需重启相应服务，运行中的任务保留自己的配置。
- 429 等待和兜底参数可在网页模型配置或经用户明确授权的 `mobile_config(section="model", persist_defaults=true)` 保存；当前任务不热切换。录屏与 AI 视频分析分别配置。批量任务的 `task_config` 可覆盖单项，不修改全局设置；只开视频分析时录制内容不作为可下载文件保存。暂停时停止录屏，恢复后按片段继续，不能把其他任务画面混入该任务资料。
- 请求重试是模型调用恢复，不是测试用例重跑。批次默认失败继续、不自动重跑；服务重启后保留状态并暂停，用户明确要求后才继续或复制失败项。
- 批次暂停只停止后续派发；当前任务等待指导时用 `mobile_manage_task(action="pause", trace_id=...)`，真正取消用 `stop`。用户明确要求删除批次记录时先 `mobile_batch(action="get")` 核对编号，再用 `delete`；执行中/排队中的批次不能删，删除会清除该批次的任务历史、报告和文件。服务重启后运行/暂停的任务标记中断，不自动重跑。停止可能保留已经产生的业务效果，不声称自动回滚。
需要编写外部可执行测试代码时，先通过 ARTEMIS 实际探索目标应用，确认页面、定位器和转换。优先动态定位，框架支持时才以已验证坐标兜底；在最终脚本中明确等待条件，不将 AI 思考耗时当作确定性等待。
执行保护默认总时限 1800 秒，单任务、批次和 MCP 都适用，排队及用户暂停不计时。设备观测默认 60 秒、最多 3 次，ADB 命令默认 10 秒；观测失败不会继续向模型发送占位图或旧元素索引。Flash 连续 3 次动作失败先重新观察再切换兜底，兜底仍失败则结束任务并保存原因。不能以提高步数或反复重提任务代替设备诊断。
`mobile_run_task(runtime_overrides={"timeout_seconds":1800,"observation_timeout_seconds":60,"observation_max_attempts":3,"device_command_timeout_seconds":10,"action_failure_attempts":3})` 可为单任务覆盖执行保护；其中 `model` 是 API 模型名，外层 `model` 仍是 Flash/Pro 模式。相同字段也支持批次的 `task_config`。全局默认通过网页功能配置或明确授权的 `mobile_config(section="capabilities", changes={"task_timeout_seconds":1800}, persist_defaults=true)` 保存，对后续任务生效，不接受密钥。
任务已经产生最终结果，但 SDK 线程或资源清理仍卡住时，默认最多再等待 30 秒后回收工作进程，避免继续占用队列。全局可用 `ARTEMIS_WORKER_CLEANUP_TIMEOUT_SECONDS` 或功能配置的 `worker_cleanup_timeout_seconds` 调整，任务 JSON 同名字段可覆盖。原有结果与截图保留，未完成保存的录屏尽力恢复。
plugins/codex/plugins/artemis-automation/skills/artemis-automation/agents/openai.yaml
-4
View File
@@ -1,4 +0,0 @@
interface:
display_name: "ARTEMIS Android 自动化"
short_description: "通过 MCP 完成 Android 单次与批量测试、失败诊断和报告交付"
default_prompt: "使用 $artemis-automation 检查设备，执行我指定的 Android 测试用例并交付有证据的报告。"
plugins/codex/plugins/artemis-automation/skills/artemis-use/SKILL.md
+47
View File
@@ -0,0 +1,47 @@
---
name: artemis-use
description: 使用 ARTEMIS 执行安卓、电脑和跨端测试，指导探索用例，排查或复盘任务，以及开发符合 ARTEMIS 规范的扩展插件。用户提到 ARTEMIS 任务编号、测试报告、缓存消耗或插件适配时使用。
---
# ARTEMIS 使用与插件开发
ARTEMIS 自己编排手机和已授权插件，共用网页的任务队列、历史与报告。主程序由用户启动；Codex 的 MCP 仅连接，不另起后台或独立执行器。主程序离线时告知用户先启动 ARTEMIS，不能反复重提任务。
## 按任务选择参考
| 用户要做什么 | 阅读什么 |
| --- | --- |
| 选择模式、执行或指导单任务 | [执行模式与操作流程](references/modes.md) |
| 边交流边探索、亲自示范、提炼复用用例 | [探索流程与 MCP 参数](references/exploration.md) |
| 批量、循环压测、选择导入项、交付资料 | [批次与报告](references/batches.md) |
| 给出任务编号，问失败原因、token、缓存、录像或最终结论 | [诊断与复盘](references/diagnostics.md) |
| 使用电脑、路由器、终端等已安装能力 | [插件任务参数](references/plugins.md) |
| 编写、适配、验证或发布 ARTEMIS 插件 | [插件开发规范](references/plugin-development.md)，按需读取 [清单与市场协议](references/plugin-manifest.md) |
只读当前任务相关参考。普通执行不加载插件开发文档。
## 三种模式
- **Flash**：路径明确的快速执行，单个执行模型观察并操作；适合冒烟、稳定流程与探索后复跑。可以接受中途指导，也有结束验收。任务长不自动等于需要 Pro。
- **Pro**：需要持久计划、多个分支、检查点、ADB/日志诊断或详细报告；按计划执行并验证。`explorer_mode` 是 Pro 的视觉定位深度，不是探索任务模式。
- **探索**：用户只有大概流程，需要与模型交流、纠正方向或人工示范；以 Pro 的执行能力推进，最终提炼一个可复用用例。超时保存并暂停，可继续。探索成功、生成用例和 Flash/Pro 复跑成功是三个不同结果。
以上是 ARTEMIS 执行模式，不是 API 模型名。每种模式的适用场景、能力差异、参数及跟踪方式见 [modes.md](references/modes.md)。沿用用户选定模式和模型；信息足够时直接执行，不反复要求批准。
## 共用规则
1. `mobile_workspace` 发现当前设备、队列、实际插件。沿用用户指定设备；多台设备而目标不明时先问。纯电脑任务用 `include_devices=false`，无需手机；普通安卓任务可按需使用已授权扩展。
2. 明确任务目标、前置条件和通过标准；用户没有要求时不擅自清数据、重装或重置环境。不假设启动时画面与旧任务相同。
3. 提交前保存唯一 `request_id`。同一次提交网络异常时保留原 ID 和内容，先反查，不用新 ID 自动重跑。模型请求重试不等于业务用例重跑。
4. 用 MCP 返回的任务编号跟踪；查看实际动作与证据，不把“已接收指导”当作“已经执行”。同一设备或桌面资源串行，其他资源可并行。
5. `completed` 只表示执行结束。读取 `test_result.status/reason/source`：passed、failed、inconclusive、blocked。人工复验优先，同时保留 AI 原判；Agent 自己的判断不能标成人工。
6. 失败或停滞先看当前任务诊断，再决定是否检查环境；不要靠连续重提测试排错。证据不足明确说明未验证，工具成功不能代替业务验收。
7. 用户明确要求删除时先查看 `deletion_preview` 的实际影响，再执行。已有明确授权不重复询问。人工复验只代录用户明确给出的通过/不通过及理由。
8. 密钥在网页或环境中配置，MCP 不接收；不读出或回显凭据。`mobile_config` 修改默认配置需要用户明确要求，临时任务用单任务配置。
9. 通过 `mobile_export_report` 交付真实路径或下载链接。手机和电脑证据按来源区分，未录到的画面不能推断。插件写操作结果不确定时先观察，不自动重复。
## 安装与版本
本目录是 ARTEMIS 管理的官方 `artemis-use`，服务启动时按内容检查并覆盖更新，不在这里定制个人规则。显式修复安装用 `artemis mcp --install codex`（源码环境前加 `uv run`）。Skill 与参考、模板一并更新；MCP 握手不安装、不启动主程序。
以当前连接服务和实际工具参数为准；旧版缺少动作时明确说明版本限制，不能假装执行成功或直接改数据库。升级 ARTEMIS 使用 `update.bat` / `update-cn.bat`，会停止该项目任务，只在用户要求升级时执行。
plugins/codex/plugins/artemis-automation/skills/artemis-use/agents/openai.yaml
+4
View File
@@ -0,0 +1,4 @@
interface:
display_name: "ARTEMIS 使用与插件开发"
short_description: "通过 MCP 执行跨端测试、交流探索、诊断复盘并开发扩展插件"
default_prompt: "使用 $artemis-use，按我的目标选择 ARTEMIS 测试、任务复盘或插件开发流程，并依据实际证据交付结果。"
plugins/codex/plugins/artemis-automation/skills/artemis-use/assets/evidence-demo/SKILL.md
+10
View File
@@ -0,0 +1,10 @@
---
name: evidence-demo
description: 按任务要求保存文本到任务资料目录，返回文件校验结果。
---
调用 plugin_load 返回映射后的 write_note 工具。只在用户需要保存文本时使用；不是任意文件读写或命令执行接口。
输入 text 不超过 16 KiB，文件名由工具生成，不能覆盖已有文件。成功后检查回执中的文件名、SHA-256 和执行状态；文件会随单任务全部资料及批次资料导出。
保存成功不代表用例通过。结果不确定时先核对任务文件，不重复写入。不自动恢复或删除用户文件。
plugins/codex/plugins/artemis-automation/skills/artemis-use/assets/evidence-demo/plugin.json
+24
View File
@@ -0,0 +1,24 @@
{
"schema_version": 2,
"id": "evidence-demo",
"name": "文件证据示例",
"version": "1.0.0",
"description": "开发模板：写入任务专属文本文件并返回校验回执。",
"artemis_version": ">=2.0.0,<3.0.0",
"platforms": ["win32", "linux", "darwin"],
"architectures": ["amd64", "arm64"],
"server": {"command": "${config.python}", "args": ["${plugin_dir}/server.py"]},
"config": {"python": {"label": "含 MCP 依赖的 Python", "default": "python"}},
"skill": "SKILL.md",
"targets": ["mixed", "computer"],
"resources": [],
"capabilities": {
"kind": "file",
"recording": "none",
"required_tools": ["write_note"],
"tools": {"write_note": {
"effect": "write", "observation": false, "idempotent": false,
"cancellation": "unknown", "evidence": ["text", "file"]
}}
}
}
plugins/codex/plugins/artemis-automation/skills/artemis-use/assets/evidence-demo/server.py
+64
View File
@@ -0,0 +1,64 @@
"""Minimal task-owned attachment server. Run through ARTEMIS, not as a shell tool."""
import hashlib
import os
from pathlib import Path
import time
import uuid
from mcp.server.fastmcp import FastMCP
from mcp.types import CallToolResult, TextContent, ToolAnnotations
mcp = FastMCP("evidence-demo")
@mcp.tool(
annotations=ToolAnnotations(readOnlyHint=False, destructiveHint=False, idempotentHint=False)
)
def write_note(text: str) -> CallToolResult:
"""Save at most 16 KiB of user-requested text as a new task attachment."""
encoded = text.encode("utf-8")
root = os.environ.get("ARTEMIS_ARTIFACTS_DIR")
if not root or len(encoded) > 16384:
return CallToolResult(
isError=True,
content=[TextContent(type="text", text="任务目录缺失或内容超过 16 KiB；未写文件。")],
structuredContent={
"artemis": {
"version": 1,
"execution": "not_started",
"side_effect": "none",
"error_code": "invalid_input",
"retryable": False,
}
},
)
directory = Path(root)
directory.mkdir(parents=True, exist_ok=True)
name = f"note-{uuid.uuid4().hex}.txt"
path = directory / name
with path.open("xb") as handle:
handle.write(encoded)
digest = hashlib.sha256(path.read_bytes()).hexdigest()
return CallToolResult(
content=[TextContent(type="text", text=f"已保存并读回校验：{name}")],
structuredContent={
"artemis": {
"version": 1,
"execution": "completed",
"side_effect": "confirmed",
"retryable": False,
"source": {
"kind": "file",
"target_id": "task-artifacts",
"label": "任务文件",
"captured_at": time.time(),
},
"attachments": [{"name": name, "sha256": digest, "media_type": "text/plain"}],
}
},
)
if __name__ == "__main__":
mcp.run(transport="stdio")
plugins/codex/plugins/artemis-automation/skills/artemis-automation/references/batches.md → plugins/codex/plugins/artemis-automation/skills/artemis-use/references/batches.md
+16
View File
@@ -66,3 +66,19 @@
`mobile_export_report(batch_id=...)` 下载批次 ZIP，包含汇总、各项报告和有序步骤截图；任务保存了录屏时，还包含对应录屏片段。报告格式由创建批次时的设置决定。单任务传 `session_id`（单任务 MCP 的 `trace_id`）以及可选 `formats=["docx"]`、`["screenshots"]`、`["video"]` 或 `["all"]`。默认格式通过 `mobile_config(section="reports")` 查看。录屏与 AI 视频分析独立，只有保存了录屏才可下载片段。 `mobile_export_report(batch_id=...)` 下载批次 ZIP，包含汇总、各项报告和有序步骤截图；任务保存了录屏时，还包含对应录屏片段。报告格式由创建批次时的设置决定。单任务传 `session_id`（单任务 MCP 的 `trace_id`）以及可选 `formats=["docx"]`、`["screenshots"]`、`["video"]` 或 `["all"]`。默认格式通过 `mobile_config(section="reports")` 查看。录屏与 AI 视频分析独立，只有保存了录屏才可下载片段。
结果文件在 MCP 主机的 `artifacts/mcp_exports/`。不要把 Office 文件内容当作文本塞入上下文；先检查工具返回的结构化结论，需要进一步审阅时再用宿主具备的文档工具打开文件。失败和未验证项也必须交付，保持原始证据。 结果文件在 MCP 主机的 `artifacts/mcp_exports/`。不要把 Office 文件内容当作文本塞入上下文；先检查工具返回的结构化结论，需要进一步审阅时再用宿主具备的文档工具打开文件。失败和未验证项也必须交付，保持原始证据。
## 精选任务与收藏复跑
`mobile_favorites(action="list")` 读取与首页相同的收藏。`create` 指定 `source_kind`（task、batch、exploration、exploration_case）和 `source_id`，从服务端原记录保存独立模板及执行配置；不传任意 snapshot，也不接受密钥。删除原任务或清理历史不影响收藏。
- task 收藏普通 Flash/Pro 任务；探索执行记录默认收藏已确认用例，无用例时保存为重新探索。
- exploration 明确保存为新的探索对话，保留原探索模型与配置；不继续旧会话。
- exploration_case 保存固定用例版本，可传 version；默认使用该版本之前的复跑配置，首次复跑默认 Flash 并明确标示。后来新版本不会覆盖已有收藏。
- batch 保存一轮用例、原顺序、循环次数及执行策略；复跑不会把已展开的执行列表再循环。
`run` 必须提供稳定的 request_id，返回新 session_id、batch_id 或 exploration_id。连接异常时沿用相同 ID 和内容重试，不能新建 ID 自动重提。changes.task_config 仅覆盖本次；批次 changes.case_configs 使用从 0 开始的用例下标，changes.task_config 统一覆盖全批。`update` 才修改收藏默认配置，可改名称。`delete` 只取消收藏，不删除历史或执行结果。
不修改时使用收藏的原配置。旧任务未记录的字段会在 inherited_fields 标明采用收藏时的默认值，不能声称全部还原。原设备离线时先让用户选择设备，不自动换机。插件仍须通过当前安装、授权和资源校验。
单任务全部资料下载按任务合并并发请求，已结束且内容未变化时复用报告和 ZIP；人工复验、结果或附件变化会重新生成。批次复用成品，人工复验后重建，旧目录格式首次下载时更新。执行中导出为当前快照。录像位于 `任务录屏/安卓/`、`任务录屏/电脑/`、`任务录屏/人工示范/`，以文件清单和证据索引为准。
plugins/codex/plugins/artemis-automation/skills/artemis-use/references/diagnostics.md
+44
View File
@@ -0,0 +1,44 @@
# 任务排查与复盘
用户给了任务编号就先针对该编号取证，不重跑业务，不停止其正在运行的任务，不把最新失败任务替换成用户指定任务。
## 定位顺序
1. `mobile_manage_task(action="status", trace_id=...)`，区分排队、执行、等待指导、暂停、收尾与终态。`current_step` 是动作步号，不等于模型请求数。
2. `mobile_inspect_trace(action="view_report", trace_id=..., offset=0, limit=20)` 读取统一结果与有限步骤。`test_result.source=human` 时同时展示 AI 原判，不能用旧 AI 结论覆盖人工复验。
3. 根据问题只读相应资料：
| 问题 | inspect action | 要核对的证据 |
| --- | --- | --- |
| 长时间没动、API 超时、no tool call | view_requests | 请求开始/结束、模型、阶段、请求ID、重试、是否终止；HTTP 200 不表示输出结束 |
| token 特别多、缓存是否生效 | view_usage，再按需 view_requests | prompt/completion/cached、调用数、角色/模型分组；未记录字段不能补猜 |
| Python、ADB、插件错误 | view_logs | 该任务 stdout/stderr 有限尾部；脱敏文本和实际错误链 |
| 点错、未验证、与结论矛盾 | search → view_step_details / view_step_screenshots | 动作前后画面、工具参数与实际回执、窗口和坐标尺寸 |
| PC 黑屏、录像空洞、文件没保存 | view_evidence | 来源、时间、录屏片段、调用回执及附件，不用手机画面代替电脑画面 |
`offset/limit` 分页，使用返回的 next_offset；view_logs 的 offset 从最新行向前计数，返回每页仍按时间正序，超过尾部读取窗口的旧字节会注明。text_truncated=true 时缩小范围或读取指定步骤，不把截断当成内容缺失。
`search` 使用 query 或 step_range，不会执行历史动作。`view_summary` 也有分页，不用它一次加载整条长任务。
## 缓存与耗时
- 缓存命中率 = cached_tokens / prompt_tokens，分母不是总 token，也不是缓存命中的请求数。
- 输入 token 包括缓存部分。报告输入总量、缓存量、未缓存输入、输出、调用数，保留缺少统计的限制。没有用量记录不等于零费用；没有价格信息不臆算账单。
- 按角色/模型分组判断消耗来源，不能把 Checker、视频分析和执行模型混为一个请求。旧数据未记录模型时注明 unknown。
- 请求阶段和重试用于解释等待，时间戳 Unix 秒及 UTC 转成用户当地时区；注明时区。无终止事件或 unknown 不能当成功。
- 区分模型生成耗时、设备/插件操作耗时、排队及用户等待。先找实际重复观测、工具参数膨胀、无进展循环，再建议优化。
- 最终验收读取 `view_requests` 返回的 `final_reviews`：核对 stage、total/elapsed/remaining_seconds、request_count、retry_count 和 status；用 review_id 关联请求的 final_review 字段。最终验收与中间检查点独立计时。budget_exhausted 是验收总预算耗尽，request_retries_exhausted 是模型请求重试耗尽，cancelled 是停止或指导中断，不能混称为 API 超时。验收耗尽不自动重跑设备操作；流式半截 passed 和验收 completed 都不能代替正式 test_result。
## 环境与插件
工具报连接/设备异常时用 `mobile_diagnose`。服务未启动时让用户先启动 ARTEMIS，不经 MCP 拉起另一个副本。一般检查先不启用付费凭据验证或真实设备探测；需要确认凭据或观测链路时再用 verify_credentials / probe_device。设备自愈用 attempt_fix，仅按返回的 next_steps 处理。
`mobile_workspace` 可见插件及 blocked_resources。只对相关已安装插件做 probe_plugin 连接检查；它会启动插件进程。结果不确定的写动作不能自动再点一次，资源保护解除由用户在网页确认。
## 结果与交付
给出具体结论、支持它的任务/步骤/请求编号、影响与缺失证据。执行失败不必然是被测产品缺陷；验收失败也不必然是工具故障。
用户只问复盘时不重新执行、不改验证结果。用户明确给出人工复验结论时，使用 mobile_manage_task(action="review", trace_id=..., review_status="passed"或"failed", review_reason=用户理由, user_confirmed=true)。AI 自己的分析不能使用这个入口冒充人工判定。
用户需要资料时再 mobile_export_report；已有 report/evidence 查看不会生成 ZIP。交付真实路径或链接，并说明未验证项。
plugins/codex/plugins/artemis-automation/skills/artemis-use/references/exploration.md
+90
View File
@@ -0,0 +1,90 @@
# 探索模式：把粗略流程变成一个可复用用例
在「新任务 / 首页」选择 Flash、Pro 或「探索」，描述要验证的大概流程，再点击「开始探索」。ARTEMIS 使用 Pro 的计划、工具和验收机制推进任务；遇到关键预期不明或需要选择时，在任务主区域提问。底部输入框用于回答问题、补充信息和纠正方向；探索还提供人工示范、暂停与继续。
工作区底部始终指导当前选中的任务：Flash/Pro 不会因此创建新任务；探索消息与操作步骤按时间排列。同一次探索在任务队列/历史中保留一张卡，内部执行轮次可展开查看，当前步骤对应所选轮次。通过「任务范围 → 探索任务」筛选。Flash/Pro 复跑各自保留普通任务卡，可点击「查看来源探索」返回；不会自动切换成探索对话。
## 模型与超时
探索独立保存模型配置，默认 `gpt-6.1-sol / high`，预设也提供 `gpt-6-astra`，允许自定义模型。执行、人工示范分析、用例提炼和结束后的讨论使用这套配置。修改默认值仅影响新探索；已创建会话保留配置快照，Flash/Pro 默认值不变。
默认每段主动执行 1800 秒。模型调用、设备动作、录像分析计入；排队、等待回答和人工示范不计入。到时保存进度并暂停，可点击「继续探索」开启下一段；不会仅因超时把测试判成失败，累计主动耗时仍保留。
普通暂停/等待回答会释放执行资源；继续后重新排队并观察设备。服务或执行进程中断后，已保存对话、证据和用例仍可用；继续会新建关联运行，不能恢复已经丢失的内存状态。
执行过程中获取设备画面超时或连接中断时，探索会保留尚未执行的指导并暂停，释放设备。确认设备恢复响应后点击「继续探索」，重新观察成功后才交给模型执行；等待期间不自动重试、不调用模型。此类暂停不等于测试失败。若设备仍不可用，会再次明确提示并暂停。
队列和历史任务以等高徽标显示「探索 / Flash / Pro」。用例复跑显示实际执行模式并另标版本；尚可继续的探索只展示当前执行状态，具体轮次的阻塞原因可在执行记录查看，结束后再展示测试结论。旧任务未保存模式时显示「模式未记录」。
## 我来操作
1. 点击「我来操作」，选择安卓、电脑或双来源，再点击「开始示范」。电脑来源要求任务已启用支持录制的插件。
2. 等界面显示「录制中」后再操作。ARTEMIS 会先让当前动作安全结束、停止 AI 操作，保留相应设备与插件资源，避免其他任务抢占。
3. 操作完成后点击「操作完成，开始分析」。ARTEMIS 停止并保存录像，分析实际画面，再显示摘要。证据明确时重新观察并继续；关键步骤或预期不清楚时再提问。
即使普通录屏关闭，人工示范仍单独录制。默认 15 分钟，最后 60 秒提醒，可以延长；到时保存录像并暂停，释放资源，不能自动视为示范完成。取消或分析失败也保留已取得的媒体，可发送文字说明继续。
录像不录音，沿用留档尺寸、帧率和编码配置。安卓与电脑分别保存并按任务时间对齐；示范分析只使用指定的已保存片段，不用手机截图代替电脑证据。画面不可见的输入和动作不能推测，用户示范不等于模型独立复跑通过。
## 用例版本与复跑
探索验收通过后提炼一个用例，包含目标、前置条件、可验证路径、等待条件和预期结果。长任务会分段提炼完整路径，原始记录保留。提炼失败不改写实际测试结论，可单独重试；未通过的探索不能自动提炼成「已验证路径」，但可以手动保存草稿。
主区域的用例卡可复制提示词，点击「查看 / 编辑」展开编辑器并保存新版本，旧版本不可变。选择已保存版本和 Flash/Pro 模式，可以指定复跑模型，也可使用普通默认模型。复跑固定版本与配置，结果与探索验收分开显示。前置条件会纳入探索用例的复跑提示词。
「加入新批次草稿」只创建批次，在「报告与批量」确认后启动。结束后仍可在对话中讨论与修订；需要再次操作设备时点击「继续探索」，它会重新排队并观察。新指导不会改写旧任务报告。
单任务和批次「全部资料」包含对话、用例版本和关联运行索引、当前任务的示范录像及原有截图/附件。其他关联任务的媒体需从对应任务导出，索引不会假称包含它们。
## MCP 与 Python SDK
更新 MCP 配置并重载后，使用 `mobile_exploration`。它与网页共用接口、队列和存储；`list/get/case` 都是只读操作。
```python
mobile_exploration(
action="create",
request_id="case-search-create",
payload={
"goal": "探索设置搜索流程；关键预期不清楚时询问我",
"task_config": {"device_serial": "用户指定的设备编号"},
},
)
# 以下 exploration_id 使用 create 返回的 id。
mobile_exploration(action="start", exploration_id="会话编号", request_id="case-search-start")
mobile_exploration(action="get", exploration_id="会话编号", after=0)
mobile_exploration(
action="message",
exploration_id="会话编号",
request_id="guide-1",
payload={"text": "只验证能打开搜索页，不修改设置"},
)
```
写操作除 `pause/stop/delete` 外均需稳定的 `request_id`；传输失败时原样重试，不生成新编号。消息 `after` 为已读最大序号；读取返回下一页，不会启动执行。运行结束看 `runs[].test_result`，不能把 `completed` 当作测试通过。
| 操作 | 参数/行为 |
| --- | --- |
| `pause/continue/stop` | 暂停/继续/明确取消当前执行 |
| `demonstrate` | `payload={source:"android"/"computer"/"both"}`；等 `demonstrations[].status=recording` 再操作 |
| `demo_finish/demo_cancel` | 传 `demonstration_id`；结束分析/取消保留媒体 |
| `demo_extend` | 另传 `payload={seconds:900}`，同一请求不会重复延长 |
| `case` | 可传 `version` 获取旧版本 |
| `save_case` | `payload={expected_version,case:{name,goal,preconditions,evidence}}`；版本冲突返回 409 |
| `generate` | `payload={source_run_id,expected_version}`；返回生成任务，轮询 `get.generations` |
| `validate` | `payload={version,profile:"flash"/"pro",task_config:{...}}` |
| `batch` | 与 validate 相同，可加 `name`；只建草稿 |
`mobile_config(section="exploration")` 读取非敏感默认值；用户授权保存后才传 `changes` 与 `persist_defaults=true`。接口不接收 API Key，模型传输仍使用已配置的 Responses 网关。
远程 SDK 的 `await client.exploration(action, exploration_id=..., request_id=..., payload=...)` 使用同样动作及参数，不创建第二套执行器。遵循当前服务返回的参数与状态。
## 对话与结束行为
- 探索助手提问后会暂停，主区域和输入框显示“等待你回答”。回答前不进行最终验收，也不生成用例。
- 新指导优先于已完成的旧计划。最终检查期间收到指导会返回执行；例如“先回到主页，再结束”需要实际完成返回操作后再验收。
- 设备操作及最终验收结束后进入“正在提炼用例”，此时不再接收设备指导。未发送文字会保留，提炼完成后可点击“继续探索”。用例卡片只在探索结束时展示。
- 进入只读最终验收前停止保存录屏，模型等待、重试与用例提炼不录入视频；如需补做操作，再录制后续片段。
- 首页探索设置使用滑块调整思考强度与时限。复跑任务显示已保存的用例名称及版本，完整提示词仍保存在任务中。
## 删除探索
用户明确要求删除时，先 `mobile_exploration(action="deletion_preview", exploration_id=...)` 查看影响；再 `delete` 并传 `user_confirmed=true`。删除整段对话及探索运行，独立 Flash/Pro 复跑保留。删除不需要 request_id；运行中或示范/提炼中不能删除。
plugins/codex/plugins/artemis-automation/skills/artemis-use/references/modes.md
+59
View File
@@ -0,0 +1,59 @@
# 执行模式与单任务流程
## 怎样选模式
| 项目 | Flash | Pro | 探索 |
| --- | --- | --- | --- |
| 适合 | 目标清楚、路径明确、低分支流程；冒烟和已提炼用例复跑 | 复杂分支、持久计划、检查点、长程监控、ADB/日志、详细记录 | 流程尚未定型，用户参与纠正或示范的一个复杂用例 |
| 执行方式 | 单执行模型观察→动作；需要时使用定位等辅助工具 | Planner 制订计划；Operator 执行；Checker 验收；按需生成报告 | 复用 Pro 工具和计划，加持续对话、提问等待、示范分析和用例提炼 |
| 验收 | 默认结束时只读验收 | 默认结束验收，可配置检查点/strict | 先处理用户指导，再验收探索目标；不把示范当独立复跑通过 |
| 中途输入 | `inject_instruction` 指导当前任务 | 同 Flash，还能记录计划及诊断信息 | `message` 持续交流；结束后消息仅讨论，再操作需 `continue` |
| 入口 | `mobile_run_task(model="Flash")` | `mobile_run_task(model="Pro")` | `mobile_exploration(create/start/...)` |
| 产物 | 步骤、证据、测试结果，按需导出报告 | 以上加计划、笔记和可选详细报告 | 对话、各轮执行和示范证据、一个用例的不可变版本 |
| 时限 | 普通执行保护，按任务配置 | 同 Flash | 默认每段主动执行 1800 秒，达到后暂停而非判失败，可继续 |
不是按步数多少机械选模式。Flash 没有默认步数上限，但不具备 Pro 的持久计划、ADB shell、过程中检查点。复杂稳定路径可以在探索确认后用 Flash 复跑；需系统诊断或检查点时用 Pro。探索不是一种更高的思考强度，Pro 的 `explorer_mode` 也不表示创建探索会话。
## 模式、模型与配置
- `mobile_run_task.model` 取 `Flash` / `Pro`。API 模型名放 `runtime_overrides.model`；思考强度放 `runtime_overrides.reasoning_effort`。批次使用 `task_config.profile` 选择模式，`task_config.model` 选择 API 模型。
- 探索独立配置，默认 `gpt-6.1-sol/high`，支持 `gpt-6-astra` 及已配置网关支持的自定义模型。执行、示范分析、提炼共用该探索配置；不改变 Flash/Pro 默认值。
- 默认 high、单次模型请求时限 300 秒。`default` 表示不发送思考强度，`none` 是显式关闭，不能混为一谈；接口不支持参数时如实报告，不擅自降级。
- 请求时限与整任务主动执行时限不同。排队/用户暂停不计入任务主动执行；探索等待回答、人工示范也不计入。
- 录屏 `record_video` 和 AI 视频分析 `analyze_video` 独立，默认关闭。需要可下载录像时明确启用录屏。
- `mobile_config(section="model"/"capabilities"/"exploration"/"reports")` 可查看非敏感默认值。用户只要求运行本次任务时用临时覆盖；只有要求保存默认值才用 `changes` 和 `persist_defaults=true`。
## Flash / Pro 提交
```python
mobile_run_task(
request_id="由调用方为本次提交生成的唯一编号",
task_desc="打开目标应用设置页，确认深色主题状态，保留证据；不要修改设置。",
model="Flash",
device_serial="用户指定的设备编号",
runtime_overrides={"reasoning_effort": "high", "record_video": True},
)
```
- 任务提示词包含目标、必要前置条件和预期。不把业务约束仅写在批次元数据里。
- `locked_app_package` 限定应用；跨应用流程不应锁定单个包。
- Pro 的 `verification_level`：off 关闭检查、final 结束检查（默认）、checkpoints 检查点加结束检查、strict 更严格检查点。关闭检查后不能把执行完成视为有验收证据。
- Pro 的 `explorer_mode`：flash 单次定位、pro 多轮定位、ultra 深度像素分析。只有明确需要时增加感知深度，避免无必要开销。
- `expected_output_desc` 描述 Pro 需要生成的详细报告；Flash 仍可导出已有步骤/结果报告，不依赖这个参数。
- 纯电脑任务 `runtime_overrides.execution_target="computer"`，不传手机编号；安卓为主且偶尔控制电脑时，通常保留默认目标并让 ARTEMIS 自行选择已授权插件，见 [插件参数](plugins.md)。
返回后保存 `trace_id`。提交回复丢失时调用 `mobile_manage_task(action="lookup", request_id=原编号)`；得到 trace_id 后查状态。`submission_state=unknown/submitting` 不等于未执行，不能换编号自动重跑。
## 跟踪、指导与结束
- `mobile_manage_task(status, trace_id)` 查询当前状态。按工具建议或约 30–60 秒间隔查询，用户正在追问时可立即查看；不无休止紧密轮询，不承诺宿主未实现的后台通知。
- `pause` 返回 pausing 只代表已接收；直到 task_paused 才能认为暂停完成。`resume` 继续原任务，恢复后重新观察并进入资源队列。
- `inject_instruction` 传 `instruction` 指导现有任务；模型等待或只读诊断可取消，已经开始的设备动作先安全结束。暂停中发送指导会恢复，用户只希望暂存文字时不要误调用。
- `guidance_history` 区分 pending/consumed，已领取仍不保证动作成功，需读后续步骤。
- Pro 连续监控的 `[Loop:continuous]` 里程碑结束使用 `release_loop=true`；自然语言“结束”不能代替明确控制信号。`stop` 用于用户要求取消当前任务。
- `completed/failed/cancelled/interrupted/skipped` 为执行终态；检查 test_result 再说明通过、失败、未验证或阻塞。人工判定附来源和原 AI 判定，不改写原始证据。
- 实际耗时受模型、网络及设备影响，不能固定扣减 5/30 秒当作精确等待。最终外部测试脚本应使用明确等待条件。
## 安卓文件
任务内部支持 `android_file`，外层以任务目标交给 ARTEMIS，文件操作也走队列。截图原生 PNG 默认留存任务 trace；明确要求桌面时额外复制并校验，不需电脑插件。读写文本、列目录、pull/push 使用目标 Android 路径及任务文件边界，不能绕过应用私有目录权限。已有文件默认不覆盖。只有工具返回实际路径及校验结果才说明保存成功；「全部资料」导出包含任务文件。
plugins/codex/plugins/artemis-automation/skills/artemis-use/references/plugin-development.md
+99
View File
@@ -0,0 +1,99 @@
# 插件开发与证据协议（2.0.0）
新插件必须适配本文规则，再通过实测进入市场。旧 `schema_version: 1` 仍可读取；新包使用版本 2，并声明 `capabilities`。模型执行、任务队列、资源锁、超时和报告由 ARTEMIS 管理，插件不另建任务调度器，也不替用户决定用例通过。
## 从可运行模板开始
模板见 [evidence-demo](../assets/evidence-demo/plugin.json)。先复制整个模板目录到用户指定开发目录；执行 `mobile_workspace(include_devices=false, include_development=true)` 获取当前 ARTEMIS 的 `development.python_executable`，将其作为 `<ARTEMIS_PYTHON>`（路径含空格时按 Shell 正确引用）。主程序未启动时也可使用用户指定 ARTEMIS 环境的 Python，先确认能 import artemis；不能假设当前工作目录是 ARTEMIS 仓库。运行：
```sh
<ARTEMIS_PYTHON> <本Skill目录>/scripts/check_plugin.py <插件目录>
<ARTEMIS_PYTHON> <本Skill目录>/scripts/check_plugin.py <插件目录> --live
```
`--live` 启动 MCP、检查真实工具定义后关闭，不执行写操作。模板默认使用 PATH 中的 Python；需要指定解释器时传 `--values '{"python":"解释器绝对路径"}'`。
网页「插件 → 高级接入」支持插件目录或 ZIP 文件的完整路径。开发时可直接填模板目录；分发时在用户指定输出目录执行以下命令，生成根层包含 `plugin.json` 的 `evidence-demo.zip`：
```sh
<ARTEMIS_PYTHON> -c "import shutil; shutil.make_archive('evidence-demo', 'zip', '用户的插件目录')"
```
模板只提供文件写入工具，没有视觉观察工具。空目录加 ARTEMIS Python 即可完成清单和握手检查；它不能独立承担纯电脑任务。完整任务验收还需已连接 Android 设备，或另一个已启用、已授权且提供观察能力的视觉插件。不要为通过检查伪造 observation 能力。
具备上述条件后，在插件设置中确认 `python` 指向已安装 MCP 依赖的解释器，再启用并提交“调用文件证据示例保存一段文本”。在任务步骤查看工具结果，下载「全部资料」查看 `任务文件/插件/evidence-demo/` 和 `证据索引.json`，回读文件并核对 SHA-256。没有设备或视觉插件时，明确交付已完成的检查和未执行的完整任务验收。
静态检查通过不等于市场准入，也不表示业务测试通过。需按下面清单提交实际验证记录。
## 清单与工具能力
`plugin.json` 的安装、版本约束、资源、权限设置沿用 [插件说明](plugin-manifest.md)。版本 2 增加：
| 字段 | 规则 |
| --- | --- |
| `capabilities.kind` | `visual`、`terminal`、`api`、`file`、`other` |
| `capabilities.recording` | `none` 或 `windows`；只有视觉插件可声明 Windows 屏幕录制 |
| `capabilities.tools` | 按真实 MCP 工具名定义；未声明和缺失工具均拒绝加载 |
| `effect` | `read` / `write`，必须如实声明 |
| `observation` | 自动观察必须只读；MCP 的 `readOnlyHint` 也必须为 true |
| `idempotent` | 重复调用是否产生额外效果，不授权自动重试未知结果的写操作 |
| `target_argument` | 指明资源目标的顶层参数名，必须存在于工具 JSON Schema |
| `cancellation` | `confirmed` / `unknown`，描述工具承诺；不能代替实际停止核对 |
| `evidence` | `text` / `image` / `file` / `state` 列表 |
| `required_tools` | Skill 依赖的工具名，加载时校验 |
MCP 参数必须有类型及合理范围；普通插件不能用不受约束的 shell 代替业务能力。终端插件若声明命令能力，应明确主机、工作目录、权限和命令边界。资源作用域用已有 `resources` 和配置约束声明；这些不是操作系统沙箱。
启动、调用、关闭分别受既有 30/60/15 秒默认预算约束，并服从任务总超时。每个写操作最多派发一次；超时、取消或部分执行后先观察真实结果。远端动作未确认停止时保持资源保护。
## 结果回执
MCP 保留标准 `content` 和 `isError`，在 `structuredContent.artemis` 返回版本 1 回执：
```json
{
"version": 1,
"execution": "completed",
"side_effect": "confirmed",
"retryable": false,
"source": {
"kind": "computer", "target_id": "真实窗口标识", "label": "控制台",
"captured_at": 1792000000.25, "width": 1280, "height": 720,
"window": {"left": 0, "top": 0, "width": 1280, "height": 720},
"screen": {"left": 0, "top": 0, "width": 1920, "height": 1080}
},
"attachments": []
}
```
- `execution`：`not_started`、`completed`、`partial`、`unknown`；`side_effect`：`none`、`possible`、`confirmed`。错误提供稳定的 `error_code` 和实际原因。只有明确未执行的请求才可声明 `retryable`，宿主仍受预算约束。
- 截图必须属于本次目标。尺寸和范围使用物理像素，时间为 Unix 秒；`target_id` 不能只是插件名。移动、缩放、换屏、换窗口后重新观察。平台结合目标和几何信息生成来源身份，避免拿旧图做动作前证据。
- 视觉工具通过标准 MCP image 返回图像；无法截图明确返回原因，不混入其他屏幕或猜坐标。终端返回退出码、输出和工作目录，API 返回状态/业务结果，文件返回校验信息，无须伪造图片。
- 平台生成 `call_id`、步骤关联、开始结束时间，并写入 trace。插件不能根据一次工具成功自行生成整条用例通过结论。
## 文件、录像与生命周期
stdio 宿主注入 `ARTEMIS_ARTIFACTS_DIR`，插件默认把生成文件写入该目录。附件回执包含普通 `name`、`media_type`、`sha256`，不接受任意宿主绝对路径；远端插件可附带 base64 `data`。单附件不超过 64 MiB，并同时受工具结果总大小限制。禁止路径穿越、符号链接和覆盖同名不同内容。
要求另存桌面时先产生并验证任务副本，再复制用户指定位置，分别报告实际结果。任一写入失败不声称全部成功。平台校验回读字节和 SHA-256，保存到任务索引；单任务和批次下载包含原生附件及插件证据。
录屏默认关闭。打开后，首次取得目标观察便启动已声明来源的录制，后续动作和等待持续录制；暂停收尾，恢复追加片段，任务结束关闭进程。电脑默认记录目标所在屏幕，可改为仅目标窗口。屏幕录像可能包含同屏其他可见内容；窗口截图仍只属于目标窗口，两者范围不同。
留档参数独立于模型截图：默认长边 1280、15 fps、H.265 目标 1000 kbps / H.264 1500 kbps。自动模式只有网页播放能力确认支持 HEVC 才尝试硬件 H.265，否则 H.264；编码不可用则有界回退并保留原因。网页使用真实任务时间轴，缺口不会被拼接抹去。H.265 的实际网页支持取决于浏览器/系统，手动优先 H.265 后无法播放应下载或为后续任务选择 H.264，不在下载时整段转码。
录制故障不能把成功动作改为失败，也不能把缺失证据推断为测试通过。录像文件只保留一套留档版本；磁盘不足停止采集并告警。不自动恢复路由器参数、电脑状态或用户文件；只有任务提示词提出恢复要求时才执行普通恢复步骤。连接关闭、进程回收和锁释放始终必要。
## 提交市场前的验证
- 公共：安装/升级兼容、真实工具与清单一致、参数限制、失败/部分执行、超时取消、版本固定、资源互斥、导出索引、卸载后历史可读、无凭据泄漏。
- 视觉：截图来源、遮挡、DPI、窗口切换、坐标一致、无图时拒绝盲点；录屏启动/结束/暂停恢复、编码回退、磁盘不足、时间缺口、关键节点、播放状态、中文可读性及长程体积。
- 文件：中文文件名、覆盖保护、校验失败；终端/API：退出码、业务结果和不确定副作用。
- Skill 必须只描述真实存在且已适配的能力，不绕过权限、调度和证据协议。保留来源和必要许可证，版本与实测范围明确；未测平台/场景不能写成已通过。
## 从第三方项目适配到市场
先核对许可证、运行平台、工具 Schema 和实际结果结构，再实现 ARTEMIS 适配；不能只复制上游 Skill 就宣称兼容。上游版本与 ARTEMIS 适配修订分别记录，例如 Cua `0.36.0+artemis.3`。
开发交付应包含 plugin.json、实现/依赖声明、插件自己的 Skill、许可证/来源、安装 ZIP 与 SHA-256、实际验证记录。静态检查和握手检查只验证对应层次，不能宣称实际操作、精度或录屏已通过。通过网页「插件 → 高级接入」导入，再经 ARTEMIS 正常任务验证时间线、暂停、证据与报告；不要绕过资源锁直接并行操作用户设备。
市场仓库为 https://git.playones.com/chenmingxuan/Artemis-Plugins 。只有用户明确要求发布/提交时才推送或发起市场提交；开发授权本身不代表发布授权。市场包使用固定版本、HTTPS 下载和 SHA-256，不覆盖同一版本的不同内容。未测平台和场景须明示。
plugins/codex/plugins/artemis-automation/skills/artemis-use/references/plugin-manifest.md
+127
View File
@@ -0,0 +1,127 @@
# 插件与跨端任务（2.0.0 开发版）
插件开发请阅读 [能力、证据协议与验收规则](plugin-development.md)，可运行模板位于 [Skill 内的 evidence-demo](../assets/evidence-demo/plugin.json)。新插件使用清单版本 2；版本 1 仍兼容。
步骤卡标明安卓、电脑等来源，可点击查看对应录像；同一步内保留实际工具调用。开启「保存录屏」后，已使用的安卓和电脑来源各自留档，通过播放器切换。电脑录屏需要插件提供版本 2 的来源回执和录像能力声明，当前市场使用 `cua-driver` 0.36.0；旧 `open-computer-use` 适配包从 1.1.0 起支持，但已从市场下架；仅更新 ARTEMIS 源码不会升级已安装插件。旧任务缺失的电脑录像无法补录，播放器会提示查看已有步骤截图。
真实时间轴保留暂停和录制中断的缺口；连续播放自动进入下一段，拖动进度到缺口时跳到下一段，并提示跳过的时间。播放器单独显示实际录制时长及蓝色录像覆盖区间；从步骤定位到未录制时间时仍明确显示缺失，不以其他时间或来源的画面替代。录像默认 1280 长边、15 fps，编码参数在功能设置的「录像留档设置」调整；不会降低模型观察截图的分辨率。
Windows x64 的窗口录像使用 Windows Graphics Capture，再交给现有 FFmpeg 编码，避免 GDI 抓取硬件加速浏览器窗口时只有黑屏。启动脚本同步 `windows-capture` 依赖；仍沿用 H.265 硬件编码与 H.264 兼容回退。窗口录制不会自动扩大为整个桌面。未取得可辨识首帧、窗口最小化/关闭或采集进程异常退出时明确记录失败原因，并保留已有片段；旧任务已经录成的黑帧无法恢复成真实视频，可查看原步骤截图。
单任务「全部资料」和批次资料包含插件截图、录像、调用回执和生成文件，`证据索引.json` 使用包内路径关联附件。电脑截图默认保存任务 trace，明确要求桌面时额外复制并校验。工具执行完成与测试通过仍分别呈现，不自动恢复业务环境。
ARTEMIS 可通过插件连接 stdio 或 Streamable HTTP MCP 服务，并按需加载插件内的 Skill。Flash、Pro、网页任务和批次复用同一套插件执行层。版本仍在开发验证中，市场只收录完成实际验证的安装包。
## 安装和配置
打开网页导航中的「插件」。可以从市场安装，或在「高级接入」导入包含 `plugin.json` 的目录/ZIP，也可以填写自定义 MCP 清单。安装不执行安装钩子，新装或升级后默认未启用。
普通使用只需「安装 → 启用」。电脑控制插件无需填写参数；首次启用时确认允许 ARTEMIS 操作电脑，授权保存在本机，以后无需重复确认。只有插件声明了必填参数时，才会打开设置表单，填写后勾选允许并「保存并启用」。
需要切换不同设备、账号或限制操作范围时，再展开「高级设置 · 多套参数与控制范围」，管理多套参数、默认设置、工具白名单、允许的参数值和共享资源。密码留空保留已保存的值；页面和 MCP 查询只返回已配置的密钥名称。不要把密钥写进清单、提示词或任务 JSON。
新装插件已有默认设置，无需创建或命名。安卓任务默认可使用支持手机扩展（targets 含 android 或 mixed）、已启用且默认设置已授权的插件。AI 先读取能力简介，需要外部操作时才加载对应工具和 Skill。任务中也可以明确选择插件；只有存在多套已授权设置时，才显示设置选择框。空列表表示不使用插件。
正在排队、暂停和执行中的任务会固定插件版本，并阻止修改配置、启停、升级或卸载。操作结束后再修改。卸载会移除插件安装文件与连接配置，历史证据仍保留。
## 执行任务
任务输入区和批次导入区保持安卓测试入口，无需选择“手机 + 电脑”。照常描述任务，例如“电脑修改路由器参数，再在手机验证并恢复”。默认收起的「扩展插件 · 自动」可展开指定插件，或取消自动选择且不勾选插件，以仅使用手机能力。
探索、Pro 和 Flash 都将插件的实际文字结果与截图交给执行模型，并保留对应调用编号；手机观察保持独立。电脑操作的步骤摘要和历史截图读取使用该次插件证据，不能用手机画面替代。若一个步骤包含多个来源的操作，查看各工具调用的截图，不把它们拼成同一屏幕的前后对比。插件没有返回图片或图片读取失败时，会明确保留证据缺失状态。
最终核验附带各来源最近两次记录的画面（最多预览八个来源，其余通过历史工具读取），标明步骤、目标和采集时间。相同前后截图保留两次观察记录并共用图片文件；画面不变只是证据，不能单凭它判定点击成功、已到页底或测试通过。核验结论按要求说明已确认、发现问题、待确认或受阻，缺证据时列出具体缺项。
Flash 和探索在电脑操作后的正时长 `wait_for_delay` 只等待，不刷新手机；等待后通过插件观察工具核对电脑状态。单独调用 `wait_for_delay(time_in_ms=0)` 才主动切回手机并读取新画面，旧手机控件编号不能继续使用。完全相同的前后截图直接生成事实摘要，避免重复请求视觉模型；其他视觉摘要将固定规则和任务目标放在稳定前缀中，实际缓存命中由模型服务返回值统计。
插件长文本默认向模型提供最多 12,000 字符的首尾节选，完整脱敏结果保存在当前任务的 `evidence/plugin-results/`。节选提示中的 `call_id` 可通过内部工具 `plugin_read_result(call_id, offset)` 分页读取，每页最多 12,000 字符；读取范围仅限本任务，不能传入任意文件路径。截图与错误状态独立保留，文本节选不代表证据缺失或验证通过。
电脑动作返回的稳定截图和控件树可直接用于下一步，切换窗口、用户接管、画面变化或证据不够时再观察。成功的只读插件步骤使用本地工具回执摘要，不再额外调用视觉模型；写操作和错误步骤仍按原流程整理证据。视觉摘要中的插件文字限为 2,000 字符，完整证据不受影响。纯观察不计入要求更新计划的连续动作数；笔记记录新结论、阻塞和关键进度，避免机械地重复读写。
Flash 在连续插件操作期间不再逐次抓取、发送无关的手机截图，电脑证据保留在对应工具返回中。切回安卓时先刷新手机画面，再由模型重新决定动作；同轮中根据旧手机编号或坐标发出的动作会暂缓执行。收到用户指导或从暂停恢复时也会重新观察，避免沿用人工操作前的画面。
高级 JSON、CLI 和 SDK 保留以下执行目标参数：
| 目标 | 含义 |
| --- | --- |
| `android` | 默认手机任务，AI 按需调用已授权扩展插件 |
| `computer` | 纯电脑任务，无需 Android；必须选择提供观察能力的插件 |
| `mixed` | 显式跨端任务；普通安卓任务无需设置此值 |
单任务 `runtime_overrides`、批次每项 `task_config` 都支持：
```json
{
"execution_target": "computer",
"plugins": [{"id": "cua-driver", "profile": "default"}],
"timeout_seconds": 1800
}
```
这只是配置引用示例，先安装并启用对应插件。不要从名字推断本机已安装它。`mobile_workspace` 返回实际插件状态和连接配置，纯电脑任务可传入 `include_devices=false` 跳过 ADB 查询；`mobile_run_task` 及 `mobile_batch` 使用现有队列。
CLI：`uv run artemis run "观察目标窗口并验证结果" --target computer --profile flash`。`--plugins-json` 可指定上面的插件引用数组。电脑和混合任务不会在队列服务失败后自动重复提交到另一执行器；`--standalone` 是显式选择本地 SDK 执行。
SDK：先 `await agent.init(execution_target="computer")`，然后 `agent.new_task(goal).with_plugins([...]).build()`。插件引用使用 `artemis.plugins.models.PluginSelection`。`for_target()` 可设置构造器目标，必须与 `Agent.init` 相符。
## 共享资源与中断
同一目标应使用同一个资源名，例如 `desktop:local` 或 `router:lab`。当前采用保守调度：任务启动时统一预留所有可用插件声明的共享资源，避免执行中跨端加锁死锁；工具与进程仍按需加载。需要独立并行的手机任务可设置 plugins: []，不占插件资源。资源名不区分大小写。不同插件操作同一路由器时也要使用相同资源名。无资源声明的 MCP 插件按插件与配置名称保守互斥。
暂停会先取消调用并关闭插件连接，再释放任务资源；恢复排队后重新观察。插件取消/超时的写操作可能已经生效，不能盲目重放。如果远程服务未确认动作停止，页面会显示资源保护及原因，用户核对后点击「已核对，解除保护」。这只解除 ARTEMIS 的保护，不会替用户终止远程操作。
工具返回成功表示调用完成，业务是否通过仍需实际证据。图片、工具文本、插件版本和动作结果进入任务记录；已有报告、截图下载和人工复验入口继续使用。Word 的「扩展插件操作」与 Excel 的「插件操作」保留来源及实际结果，资料包截图名称含插件 ID。同一截图被多个任务引用时，删除最后一个任务后才清理。插件画面与手机截图属于不同来源，不能相互替代。电脑录像从首次取得有效窗口画面开始，按实际来源留存；启动失败或中断会保留状态和原因。
## 插件清单
```json
{
"schema_version": 2,
"id": "lab-control",
"name": "实验室控制",
"version": "1.0.0",
"artemis_version": ">=2.0.0,<3.0.0",
"platforms": ["win32"],
"architectures": ["amd64"],
"targets": ["mixed"],
"server": {
"transport": "stdio",
"command": "${plugin_dir}/bin/server.exe",
"args": [],
"env": {"TOKEN": "${secret.token}"}
},
"skill": "SKILL.md",
"config": {"token": {"label": "连接密钥", "secret": true, "required": true}},
"resources": ["router:lab"],
"capabilities": {
"kind": "api", "recording": "none", "required_tools": ["read_status"],
"tools": {"read_status": {
"effect": "read", "observation": false, "idempotent": true,
"cancellation": "confirmed", "evidence": ["state", "text"]
}}
}
}
```
HTTP 服务使用 `{"transport":"streamable_http","url":"https://example.com/mcp","headers":{"Authorization":"Bearer ${secret.token}"}}`。配置引用支持 `${config.字段}`、`${secret.字段}` 和 `${plugin_dir}`；参数直接以 argv 启动，不经 shell。纯 Skill 可省略 `server`。Skill 的引用文件必须在包内，按需读取支持不超过 256 KiB 的 Markdown、文本和 JSON。
提供电脑画面观察的插件声明 `observation`，其中 `tool` 和 `arguments` 为初始观察调用，`refresh_tools` 为模型选择目标后可复用的只读观察工具名。例如初始列窗口，选择窗口后每步刷新该窗口。观察允许只返回文字；无图时不能伪造截图或推测像素坐标。
清单提供的工具和参数范围检查不是操作系统沙箱；第三方进程以当前用户权限运行。市场包使用 HTTPS、SHA-256、平台/版本检查及安全解压，包内应保留许可证和来源记录。
市场索引为 `{"schema_version":1,"plugins":[...]}`，每项包含 `manifest`、`archive_url`、`sha256`、`verification`，以及 release_stage（stable 或 preview，默认 stable）。开发预览在市场明确标注，并提供已验证范围和未覆盖场景。同一版本不可覆盖，先验证新包再使用新版本号。
## 环境参数
| 环境变量 | 默认值 |
| --- | --- |
| `ARTEMIS_PLUGIN_MARKETPLACE_URL` | Artemis-Plugins 仓库的 catalog.json |
| `ARTEMIS_PLUGIN_START_TIMEOUT_SECONDS` | 30 秒 |
| `ARTEMIS_PLUGIN_TOOL_TIMEOUT_SECONDS` | 60 秒 |
| `ARTEMIS_PLUGIN_SHUTDOWN_TIMEOUT_SECONDS` | 15 秒 |
| `ARTEMIS_PLUGIN_DOWNLOAD_TIMEOUT_SECONDS` | 300 秒 |
| `ARTEMIS_PLUGIN_DOWNLOAD_MAX_BYTES` | 128 MiB |
| `ARTEMIS_PLUGIN_EXTRACT_MAX_BYTES` | 512 MiB |
| `ARTEMIS_PLUGIN_RESULT_MAX_BYTES` | 16 MiB |
修改环境参数后重启开发版服务。任务总时限仍由现有执行保护控制，插件不会自行无限重试。
plugins/codex/plugins/artemis-automation/skills/artemis-use/references/plugins.md
+26
View File
@@ -0,0 +1,26 @@
# 插件任务参数
先调用 `mobile_workspace`，只选实际存在、已启用且配置已授权的插件。纯电脑任务使用 `include_devices=false`，避免不必要的 ADB 查询。通过现有 `mobile_run_task` 发起电脑任务：
```json
{
"request_id": "本次提交的唯一编号",
"task_desc": "观察已打开的测试控制台，确认参数值符合用户预期，并保留证据。",
"model": "Flash",
"runtime_overrides": {
"execution_target": "computer",
"plugins": [{"id": "cua-driver", "profile": "default"}],
"timeout_seconds": 1800
}
}
```
示例中的插件必须已安装；不要为解决缺插件而调用宿主私有电脑工具代替 ARTEMIS 执行。`computer` 无需 `device_serial`，`mixed` 同时需要手机与插件资源。批次每个用例的 `task_config` 使用相同字段，可混合不同配置和执行目标。
未提供 `plugins` 表示使用该目标下已启用插件的授权默认配置；空数组明确不用插件。只提供插件 ID 和配置名称，版本由服务在入队时固定。安装、授权、连接凭据和资源保护解除由用户在插件页面处理。
插件超时/取消后先查任务状态和错误，不自动重放点击或配置写入。`mobile_workspace.blocked_resources` 非空时说明存在尚未确认停止的资源，不能声称暂停已安全完成。工具返回成功还需从后续画面或结构化读数验证业务结果。
普通安卓测试无需指定 execution_target 或 mixed：省略 plugins 时，AI 可以按需加载已启用、默认配置已授权且支持 android/mixed 的插件。仅需手机能力或不希望预留桌面资源时使用 plugins: []。网页、MCP 和批次采用相同规则。
连接失败可使用 `mobile_workspace(include_devices=false, plugin_id=实际插件ID, probe_plugin=true)`；它会启动已授权插件做连接和工具声明检查，不执行测试动作。读取清单不等于实测通过。
plugins/codex/plugins/artemis-automation/skills/artemis-use/scripts/check_plugin.py
+47
View File
@@ -0,0 +1,47 @@
"""Validate a plugin package; --live checks MCP declarations without executing actions."""
import argparse
import asyncio
import json
from pathlib import Path
from artemis.plugins.evidence import validate_tools
from artemis.plugins.models import PluginManifest, PluginProfile
from artemis.plugins.session import PluginSession, resolve_server
from artemis.plugins.store import contained_path
async def check(directory: Path, live: bool, values: dict[str, str]) -> None:
manifest = PluginManifest.model_validate_json((directory / "plugin.json").read_text("utf-8"))
manifest.check_compatible()
if manifest.skill:
skill = contained_path(directory, manifest.skill)
if not skill.is_file() or not skill.read_text("utf-8").strip():
raise ValueError("缺少有效的 Skill")
if manifest.schema_version != 2:
raise ValueError("新市场插件必须适配 schema_version=2")
if live and manifest.server:
server = resolve_server(manifest, PluginProfile(values=values), directory)
session = await PluginSession(server, directory).start()
try:
validate_tools(manifest, session.tools)
finally:
await session.aclose()
print(
f"PASS {manifest.id} {manifest.version}: 清单/兼容性/Skill"
+ ("/MCP 工具声明" if live else "")
)
print("此检查不代替实际执行、超时取消、证据导出和视觉能力验收。")
def main() -> None:
parser = argparse.ArgumentParser(description=__doc__)
parser.add_argument("directory", type=Path)
parser.add_argument("--live", action="store_true")
parser.add_argument("--values", default="{}", help="普通配置 JSON；不得包含密钥")
args = parser.parse_args()
asyncio.run(check(args.directory.resolve(), args.live, json.loads(args.values)))
if __name__ == "__main__":
main()
plugins/codex/plugins/artemis-case-prep/.codex-plugin/plugin.json
+1 -1
View File
@@ -1,6 +1,6 @@
{ {
"name": "artemis-case-prep", "name": "artemis-case-prep",
"version": "1.1.0", "version": "1.2.0",
"description": "从 Android 原始测试工作簿筛选可由 ARTEMIS 自动化的用例，标记原表副本并生成七列任务表。", "description": "从 Android 原始测试工作簿筛选可由 ARTEMIS 自动化的用例，标记原表副本并生成七列任务表。",
"author": { "author": {
"name": "hejunxian", "name": "hejunxian",
plugins/codex/plugins/artemis-case-prep/THIRD_PARTY_SOURCE.json
+3 -3
View File
@@ -1,9 +1,9 @@
{ {
"sourceId": "artemis-case-prep", "sourceId": "artemis-case-prep",
"repo": "https://git.playones.com/hejunxian/artemis-case-prep.git", "repo": "https://git.playones.com/hejunxian/artemis-case-prep.git",
"ref": "v1.1.0", "ref": "v1.2.0",
"commit": "e1e094513f4b9360231022f6d18a0ebc6a04dc7d", "commit": "f0b9fc6efac82f825ffc27051a04d47f22ba5362",
"adapter": "claude-skill", "adapter": "claude-skill",
"sourcePath": ".", "sourcePath": ".",
"syncedAt": "2026-09-28T10:12:45Z" "syncedAt": "2026-10-21T06:48:34Z"
} }
plugins/codex/plugins/artemis-case-prep/skills/artemis-case-prep/SKILL.md
+42 -8
View File
@@ -1,12 +1,16 @@
--- ---
name: artemis-case-prep name: artemis-case-prep
description: 从多工作表原始 Android 测试用例中筛选适用于目标设备且可由 ARTEMIS 自动执行的用例，核实测试环境和用例信息后标记原表副本，并填写七列批量任务模板。用于准备任务文档，不用于直接运行批次或改造导入器。 description: 从多工作表原始 Android 测试用例中筛选适用于目标设备且可由 ARTEMIS 自动执行的用例，核实测试环境和用例信息后标记原表副本，并填写七列批量任务模板。也用于依据已有 ARTEMIS 运行证据修订任务提示词；不用于直接运行批次或改造导入器。
metadata:
version: "1.2.0"
--- ---
# ARTEMIS 用例准备 # ARTEMIS 用例准备
把原始测试用例工作簿转成两份可追溯的文件：保留原有内容并新增“是否选中作为自动化执行”（`是`/`否`）列的原表副本，以及只包含选中用例的七列任务表。优先使用用户提供且符合下述七列表头的模板；未提供时使用 [七列模板](assets/artemis-tasks.xlsx)。不要覆盖输入文件。 把原始测试用例工作簿转成两份可追溯的文件：保留原有内容并新增“是否选中作为自动化执行”（`是`/`否`）列的原表副本，以及只包含选中用例的七列任务表。优先使用用户提供且符合下述七列表头的模板；未提供时使用 [七列模板](assets/artemis-tasks.xlsx)。不要覆盖输入文件。
首次转换按下述适用性与信息完整性要求准备正式文件；已有任务表复盘时，按 [依据已有运行修订提示词](#依据已有运行修订提示词) 处理。参考文件中的历史环境、批次、条数、路径和用户确认只在可对应的原项目内适用，不能代替当前用户的确认。仅要求更新 skill 时只修改技能文件。
## 先确认适用性，再判断自动化 ## 先确认适用性，再判断自动化
1. 逐页识别真正的用例表、表头、续行、合并单元格及行级适用性；不要以固定列号、`max_row` 或单独的用例编号推断用例。行政清单、报告页和空白格式行不算用例。遇到本项目附件的异构页时，读 [字段与边界](references/workbook-contract.md)。其他原始文档仍须按其实际结构重新识别。 1. 逐页识别真正的用例表、表头、续行、合并单元格及行级适用性；不要以固定列号、`max_row` 或单独的用例编号推断用例。行政清单、报告页和空白格式行不算用例。遇到本项目附件的异构页时，读 [字段与边界](references/workbook-contract.md)。其他原始文档仍须按其实际结构重新识别。
@@ -22,24 +26,54 @@ description: 从多工作表原始 Android 测试用例中筛选适用于目标
- 在原表**副本**的用例表增加且只增加所要求的自动化标记列（若已有此列则更新，不重复新增）；每条用例填 `是` 或 `否`。先核对目标位置不会覆盖既有数据，保留原工作表、原文、图片、合并、格式及非用例页。若所选表格工具不能保真，停止交付并说明损失，不输出貌似完整的副本。遵循可用的 spreadsheet 工作流进行编辑、渲染与导出检查。 - 在原表**副本**的用例表增加且只增加所要求的自动化标记列（若已有此列则更新，不重复新增）；每条用例填 `是` 或 `否`。先核对目标位置不会覆盖既有数据，保留原工作表、原文、图片、合并、格式及非用例页。若所选表格工具不能保真，停止交付并说明损失，不输出貌似完整的副本。遵循可用的 spreadsheet 工作流进行编辑、渲染与导出检查。
- 任务表严格沿用 `任务` 页的七列顺序：`用例编号 / 检测项目 / 测试子项 / 测试用例 / 前置约束提取 / Artemis提示词 / 任务配置(JSON)`。只写入适用且自动化列为“是”、提示词所需信息已补齐的用例；其他工作表保持模板原样。`用例编号` 只填写原表显示的编号，不附 `（Sheet1!2）`、`〔来源页!行号〕` 等工作表/行号后缀；原表编号不改。重复编号保持原样，处理时另以来源工作表和行号定位用例。`Artemis提示词` 是唯一提交给 AI 的任务正文，其他文本列只作元数据，不自动拼入提示词。 - 任务表严格沿用 `任务` 页的七列顺序：`用例编号 / 检测项目 / 测试子项 / 测试用例 / 前置约束提取 / Artemis提示词 / 任务配置(JSON)`。只写入适用且自动化列为“是”、提示词所需信息已补齐的用例；其他工作表保持模板原样。`用例编号` 只填写原表显示的编号，不附 `（Sheet1!2）`、`〔来源页!行号〕` 等工作表/行号后缀；原表编号不改。重复编号保持原样，处理时另以来源工作表和行号定位用例。`Artemis提示词` 是唯一提交给 AI 的任务正文，其他文本列只作元数据，不自动拼入提示词。
- `任务配置(JSON)` 可留空，表示继承批次或全局配置；确需逐项覆盖时，只写当前 ARTEMIS 导入器支持的字段和值，使用合法 JSON 对象，不写密钥、占位值或未经确认的设备序列号。模拟器名称和被测设备名称不能当作 `device_serial`；填写前核对实际序列号。字段及导入边界见 [七列契约](references/workbook-contract.md#模板)。 - `任务配置(JSON)` 可留空，表示继承批次或全局配置；确需逐项覆盖时，只写当前 ARTEMIS 导入器支持的字段和值，使用合法 JSON 对象，不写密钥、占位值或未经确认的设备序列号。模拟器名称和被测设备名称不能当作 `device_serial`；填写前核对实际序列号。字段及导入边界见 [七列契约](references/workbook-contract.md#模板)。
- “前置约束提取”写目标测试 App 版本及原文实际要求的设备、账号、网络和状态；一致性用例还写明比较字段与独立预期值/来源，草稿中可明确标出待补项，但不把未确认条件写成已满足。“Artemis提示词”**必须以 `【原表显示的用例编号】` 紧接原“测试用例”文本开头**，随后接完整执行说明；例如 `【1.1】【声波配网】手动长按重置恢复出厂后首次绑定完成配网流程` 后另起执行说明。这里的连接是文本拼接，不写字面 `+`；提示词前缀不附来源页/行号。执行说明写明沿用测试开始前统一核验的 App 版本，不要求每条用例再次检查；还须写明起点、操作意图、必要等待/状态转移、可观察的预期及判定方式；一致性断言须明确实际值与哪个预期值比较。直播页的分辨率切换、全屏、声音开启/关闭等目标控件初次未显示时，可先观察画面、轻点直播画面一次并重新观察可能浮现的控件或二级菜单；声音开关仅以可观察的 UI 状态核验，不把需要人工听音的结果判为自动化可核验。卡回看和云回看可将有颜色区域作为有数据的选时线索、空白区域作为无数据线索；选有数据片段时先选择过去且有颜色的区域，再用回放结果核验，不仅凭颜色判通过，也不设计拖动到未来。**仅移动爱家 App** 的卡回放用例可在点击“云回看”后观察是否出现切换入口。以上均是适用场景的条件性提示，不发明 UI 定位器、页面路径、精确坐标或功能。无可用原编号或测试用例文本时列出来源行请用户补齐，不造编号或标题。给 Codex 的通用截图、录屏、证据归档及结论要求不写入“Artemis提示词”；更多写法见 [字段与边界](references/workbook-contract.md)。 - “前置约束提取”及每条正式“Artemis提示词”均须包含已确认的模拟器名称或真机环境、测试 App 名称与版本、被测设备名称，以及本条实际所需的账号、网络、状态等前置；一致性用例写明比较字段及独立预期值/来源。可在执行时只读取得的既有配置、实际名称和本次操作起止，不强制用户事先手填；独立预期、适用性、外部场景等仍须落实。尚缺资料只列单独待补清单，未补齐时不编写该条正式提示词，不把占位内容放进任务表。
- “前置约束提取”及每条正式“Artemis提示词”都要写明已确认的模拟器名称或真机环境、测试 App 名称与版本、被测设备名称。执行说明沿用测试开始前统一核验的安装版本，不要求逐条再查。用例缺失的操作、前置或预期信息只列在单独的待补清单中；补齐前不写该条提示词，也不将占位内容放进任务表。 - “Artemis提示词”必须以 `【原表显示的用例编号】` 紧接原“测试用例”文本（仅去首尾多余空白）开头，再另起完整说明。例如 `【1.1】【声波配网】手动长按重置恢复出厂后首次绑定完成配网流程`；连接是文本拼接，不写字面 `+`，不附来源页/行号。原编号或用例文本缺失时请用户补齐，不造编号或标题。执行说明写明沿用测试前统一核验的 App 版本、实际起点、操作意图与顺序、必要等待/状态转移、可观察预期及判定方式，不要求逐条再查版本。保留原量词、时长、观察端和判据，不发明界面路径、定位器、坐标或功能，不把相邻用例动作塞入共用段。
- 每条“Artemis提示词”在完成本用例的操作和结果观察后，要求返回目标 App 内的设备首页并确认首页可见；用例失败或未验证时也应尝试返回。不要把 Android 系统桌面当成设备首页，也不要编造返回路径。若因解绑、页面异常等原因无法返回，说明最终页面和原因。Codex 在开始下一条前核对设备首页已恢复；未恢复时先处理状态问题，避免用例相互干扰。 - 先按 [用例完成检查与收尾](references/workbook-contract.md#用例完成检查与收尾) 逐项核对本条必需操作和结果观察。某项失败、弹窗文案不同或缺少部分断言依据时，保留该项结果，继续可独立执行的操作与回读；仍能补做的漏项先补完。全部必要项完成，或剩余项有具体阻碍且有限恢复无效，或用户取消/实际预算终止时，再收尾。“失败或未验证也收尾”不表示首个偏差即可结束。
- **移动爱家 App** 点击“设置”进入设置页后，先等待页面刷新出实际设置内容并重新观察，确认目标控件属于刷新后的页面，再进行点击或滑动；不能把刚进入时的空白、占位或旧页面当作最终内容。设置页功能项较多；相关用例在已加载的首屏未找到目标时，提示词应允许向上滑动更长距离以查看下方内容，并在每次滑动后重新观察和定位。不要把首屏未见当作功能缺失，也不要规定未经核实的固定等待时间、坐标、距离或盲滑次数；见 [设置页查找边界](references/workbook-contract.md#提示词与决策)。 - **移动爱家用例保留强制停止收尾**：完成本条操作和观察、达到上述退出条件后，强制停止 `com.cmri.universalapp`；失败或未验证同样执行。执行端有实际可用的应用停止能力时可直接使用，支持 ADB 时可用 `am force-stop com.cmri.universalapp`。执行端不支持或停止失败，由 Codex 在本条结束、设备空闲且下一条尚未启动时通过宿主 ADB 补做；开始下一条前确认主进程及 `com.cmri.universalapp:` 前缀子进程均已停止，未确认则先处理收尾。下一条重新启动 App、等待加载并建立本条前置。用户当前明确另有收尾安排时按其要求；其他 App 按该任务约定，未约定时返回 App 内设备首页并确认，不误用移动爱家包名，也不把系统桌面当设备首页。
- 核对原表每条真实用例的标记均为 `是`/`否`，待确认条目全部处理后，任务表数据行数恰等于“是”的数量；逐行检查编号列只含原表显示的编号、提示词的编号和用例文本前缀，且每条提示词都要求结束时返回 App 内设备首页；核对模拟器或真机环境、App 名称与版本、被测设备名称与用户确认值一致，且提示词没有逐条核验版本、通用截图录屏、证据归档或结论指令。第七列应为空或为可解析、仅含受支持字段的 JSON 对象。抽查一致性用例有独立参照且比较字段明确，再抽查不同表头布局、重复编号、合并/续行和排除项。确认输入文件未改、两份输出的非目标内容未意外变化，且七列表头、提示词与来源可回溯。 - 按本条场景读取下表，采用实际适用的操作，不把专项数值和历史入口推广为所有用例的默认值。
本七列模板与当前查看的 ARTEMIS `task_import.py` 表头一致，但不能仅凭表头声称文件已通过导入。用户将来要求执行时，先用当时服务的预览校验，再按执行授权启动；本 skill 不改导入器、不调用 `mobile_batch`、不启动设备。编写外部可执行测试代码则先用 ARTEMIS 探索实际应用。 | 场景 | 需要读取及核对的规则 |
| --- | --- |
| 直播清晰度、全屏、声音等短时浮层 | [短时浮层与连续操作](references/transient-controls.md)：首次用同动作早帧识别入口，核对当前布局；已定位入口在实际支持的短序列内完成唤出与点击。声音图标只证明 UI 状态，不能代替听音；旧早帧不是当前状态。 |
| 设置长列表、表单、云台、计划、图片操作 | [提示词与决策](references/workbook-contract.md#提示词与决策) 及 [设置页查找](references/workbook-contract.md#设置页查找与到底确认)：移动爱家设置先等实际内容刷新；未见目标时按实际进展继续查看下方及相关子页，核实到底，不固定盲滑次数。仅对已对应项目采用16.1等用户专项例外。 |
| 云回看、卡回放与选时 | [回看选时](references/workbook-contract.md#提示词与决策)：按实际存储类型、日期、时区与过去区间选时；颜色只作线索，灰色也可能有数据，以回读与实际播放核验。难定位时可点击实际可见“+”放大时间轴，再拖蓝色光标并回读，精确时间要求不放宽。仅移动爱家卡回放可在“云回看”后观察切换入口。本次生成型回看先完成规定档位及真实时长，再查对应新录像，不用旧片段替代。 |
| 分辨率截图与相册核验 | [设备截图分辨率与相册查看](references/workbook-contract.md#设备截图分辨率与相册查看)：识别本次截图原图、读取宽×高，与已确认预期比较；核对本条有效应用锁定配置允许切换相册，核验后按本条约定收尾。 |
| 持续播放、等待、录像与预算 | [长时任务预算与实际计时](references/workbook-contract.md#长时任务预算与实际计时)：用可靠起点、截止和剩余时长，保留原业务时长；单条有效预算须包含启动、定位、测量、有限恢复和收尾。30分钟业务不能仅给1800秒总时限，可按实际流程在受支持的单条配置覆盖如 `{"timeout_seconds":3600}`，保留其他配置，不改全局默认。 |
| 既有编码、AOV、云/卡回看专项 | [编码与回看补充](references/encoding-playback-feedback.md) 及 [既有项目反馈](references/project-feedback.md)：按对应原文、版本和用户确认应用，区分 App 业务录像与操作录屏、各组合实际计时、设置回读和业务效果。 |
- 给 Codex 的通用截图、录屏、证据归档、结论和模型诊断要求不写入每条“Artemis提示词”。用户明确指定的画面截图、操作视频、日志地址/文件等本条交付物，可以写明动作、数量、时段及关联方式；操作录屏必须通过受支持的单条配置实际开启，不能只写提示词，也不以 App 内录像替代。采集完成与业务通过分别核验。
- 正式输出前确认所有真实用例的自动化标记均为 `是`/`否`、所有待确认项已处理，任务数据行数恰等于“是”的数量。逐行核对原编号、提示词原文前缀、四项环境、原动作/判据及约定收尾；移动爱家包名和进程检查准确。第七列为空或为仅含支持字段的可解析 JSON 对象。抽查独立比较参照、异构表头、重复编号、合并/续行和排除项；核实输入未改、非目标内容保真、模板七列及来源可追溯。提示词不得出现逐条查版本、通用归档或模型诊断口令。
本七列模板沿用已查看的 ARTEMIS `task_import.py` 契约，不能仅凭表头声称已导入。用户以后要求执行时，由执行方用当时服务的预览校验核实真实支持字段和逐行错误，再按执行授权启动。本 skill 不改导入器、不调用 `mobile_batch`、不启动设备；编写外部可执行测试代码前须用 ARTEMIS 探索实际应用。
## 依据已有运行修订提示词
用户要求复盘任务或重出既有任务表时，沿稳定 batch ID、session/trace ID 与原用例对应，读取 [已有任务表复盘修订](references/workbook-contract.md#已有任务表复盘修订)。分别保留原终态、业务判定、Checker、实际步骤和复核结论，按证据修正本条的范围、前置、定位、时序和断言；用户新确认路径不冒充旧 trace 已走通，历史 `completed` 不证明业务通过。发现提示词、执行器观测或模型链路问题时分别记录，技能文字修改不代表后端修复或设备复测完成。
默认以用户指定或最新已交付的七列 `.xlsx` 为底稿，只回填受影响行的完整提示词和必要单条配置，交付保留其他用例、原编号/顺序、环境、辅助页、样式及批注的新副本，不覆盖底稿。上次交付后已定稿且尚未回填的相关修订一并带入。用户明确仅要单条或其他格式时按其要求。只有用户明确要求全量重审才逐条改写全量，不因单条优化、更新 skill 或历史完成状态自动增删集合。
用户明确改为操作、指定截图/视频/日志采集及人工判断时，按新范围编写，保留原判据及人工待判，不用首次全自动筛选规则排除整条，也不把采集成功写成产品通过。暂不适用用例从可导入的“任务”页移出，不伪造 `enabled`/`skip` 字段。用户要求保留全量但条件未齐时，可另交明确标识的审阅稿和待补清单；不得混为正式可派发表或自动改原表标记。
仅在当前请求可明确对应来源项目时，读 [既有项目反馈与专项修订](references/project-feedback.md)；其中68条集合、删除清单、固定环境、V6/V7、数值、特殊入口及桌面命名只用于该项目，具体规则与 [覆盖核验](references/workbook-contract.md#本轮68条重出与覆盖核验) 对照。新项目按实际资料重新识别；交付位置沿用当前请求或工作区输出约定。没有当前底稿而需回填时再核实来源，不因只修改 skill 自动生成任务表。
## Codex 执行与证据归档（不写入 Artemis 提示词） ## Codex 执行与证据归档（不写入 Artemis 提示词）
后续正式执行前，执行方须实际确认登录状态、目标设备可见及本轮所需在线状态，不能只核验安装版本就视为执行环境已就绪。用户已授权自动登录且存在现有账号、已保存凭据或可用免密入口时，按实际界面尝试并观察反馈；密码框显示占位文字或看似为空，不足以断定缺少凭据。只有实际登录反馈或必要输入明确缺失时才记录对应阻碍，不猜造密码、验证码或登录路径。登录成功与本轮所需设备状态分别核验；用例或本轮要求核对固件时，另按已确认目标核验。共同的登录障碍应作为环境问题关联受影响用例。
以下是已有任务表的后续执行约定，不替代前文准备正式任务表的待补要求。用户已明确“全量处理、遇阻先跳过并继续”时，执行方在派发前核对人工、实物或外部工具条件；可独立执行的部分继续核验，核心动作或断言全部依赖未具备条件的条目直接记录跳过/阻塞、缺失条件与未执行分支，不交给 Flash 等待其解决外部条件。“全量处理”应保留每条用例记录，不表示条件已具备或断言已通过。沿用用户已选安排，不逐条重复索取同一条件，不将受阻项判为产品失败或通过。
后续执行测试时，Codex 在关键操作前后截图并保留本任务录屏；记录证据路径，以便归档到工作区“测试佐证”目录。若工具只能保存到 ARTEMIS trace，报告 trace 和证据路径。前置条件不成立、控件未找到或证据不能证明预期时，如实报告阻塞或未验证，不写通过。这些要求由 Codex 处理，不拼入任务表每条“Artemis提示词”。 后续执行测试时，Codex 在关键操作前后截图并保留本任务录屏；记录证据路径，以便归档到工作区“测试佐证”目录。若工具只能保存到 ARTEMIS trace，报告 trace 和证据路径。前置条件不成立、控件未找到或证据不能证明预期时，如实报告阻塞或未验证，不写通过。这些要求由 Codex 处理，不拼入任务表每条“Artemis提示词”。
短时控件“点击后未见”时，执行方按 [瞬态取证与诊断](references/transient-controls.md#执行方的取证与诊断) 对齐真实落点、首次有效画面或已有录像及后续观测时序，区分点错位置、曾显示后隐藏和未取得短时证据。保留即时截图、调整观测策略及诊断 helper/UIAutomator2 属于执行方职责；本 skill 只编写相关操作意图与交接要求，不启动设备、修改后端或改变全局默认。
执行方先区分已声明的业务等待与模型停滞，不能只因 UI 步骤不增长就中断合法计时。模型请求反复超时、仅间歇恢复少量动作时，也按 [异常超时复盘](references/workbook-contract.md#已有任务表复盘修订) 核查跨回合累计耗时、实际目标进度、预算及收尾，不能用一次成功点击或短等待清除异常审计，不把等待模型当作业务观察；长时业务则核对实际等待参数、截止时间及剩余总预算。异常工具参数、重试和停滞监控由执行方处理，不向每条业务提示词追加自我催促、重试口令或固定模型等待；本 skill 的文字修订不能代替执行层的参数校验与超时修复。
## 执行状态显示取消但之后完成 ## 执行状态显示取消但之后完成
ARTEMIS 执行期间，网页或列表可能显示“取消”/“正在取消”，而之后的持久批次或任务记录又显示已完成。不要依据单次界面快照判最终状态，也不要把“已完成”直接等同于测试通过。执行方应按稳定的批次 ID、session/trace ID 重新读取 ARTEMIS 持久状态，确认取消是否只是请求/过渡状态、任务最终状态，以及报告是否已就绪；检查应遵从工具建议并保持低频，避免连续轮询。 ARTEMIS 执行期间，网页或列表可能显示“取消”/“正在取消”，而之后的持久批次或任务记录又显示已完成。不要依据单次界面快照判最终状态，也不要把“已完成”直接等同于测试通过。执行方应按稳定的批次 ID、session/trace ID 重新读取 ARTEMIS 持久状态，确认取消是否只是请求/过渡状态、任务最终状态，以及报告是否已就绪；检查应遵从工具建议并保持低频，避免连续轮询。
- 最终持久记录为 `completed` 且报告已就绪时，核对 trace/报告中的实际步骤、证据和业务判定，再分别记录通过、失败或未验证。 - 最终持久记录为 `completed` 且报告已就绪时，核对 trace/报告中的实际步骤、证据和业务判定，再分别记录通过、失败或未验证。
- 最终持久记录为 `cancelled` 时，它是终态；保留取消记录及已产生的部分证据，不得改写成完成，也不要因界面状态不一致而自动重提同一用例。重跑须有明确授权，并作为新的执行记录。 - 最终持久记录为 `cancelled` 时，它是终态；保留取消记录及已产生的部分证据，不得改写成完成，也不要因界面状态不一致而自动重提同一用例。确认终态后，按同一运行 ID 核对最新保存步骤及对应画面；若检查或取消期间又完成了动作，更新已执行范围，不沿用取消前快照的未执行结论。重跑须有明确授权，并作为新的执行记录。
- 若批次、session 与网页显示互相矛盾，或报告尚未就绪，记录各自 ID、状态和检查时间，做必要的低频只读核验；矛盾未消除前标记“状态待核实”，不得统计为通过或已完成。 - 若批次、session 与网页显示互相矛盾，或报告尚未就绪，记录各自 ID、状态和检查时间，做必要的低频只读核验；矛盾未消除前标记“状态待核实”，不得统计为通过或已完成。
此规则只用于解释执行记录，不改变本 skill 的职责范围：本 skill 负责准备与核验用例文档，不负责启动、取消、恢复或重跑 ARTEMIS 任务。 此规则只用于解释执行记录，不改变本 skill 的职责范围：本 skill 负责准备与核验用例文档，不负责启动、取消、恢复或重跑 ARTEMIS 任务。
plugins/codex/plugins/artemis-case-prep/skills/artemis-case-prep/assets/artemis-tasks.xlsx
BIN
View File
Binary file not shown.
plugins/codex/plugins/artemis-case-prep/skills/artemis-case-prep/references/encoding-playback-feedback.md
+92
View File
@@ -0,0 +1,92 @@
# 编码、直播录像与回看补充
用于依据用户 2026-10-20 对编码与回看运行的两轮反馈修订任务表，第二轮重点为9.101、9.122、9.139和12.14。本文的数值、路径及日期/刻度是这些用例在本轮已确认的要求，其他设备、App 或用例按自己的原文与实际界面确定；不将示例升级为全局默认。运行 ID 用于对应原行，用户反馈与实际 trace 分别注明来源，不把补充要求写成旧运行已执行或通过的证据。
## 写入任务表的共同规则
- 每个被测状态均完成“设置并保存回读 → 在该状态仍生效时观察直播或录制 → 再切下一态”。开关成功与直播正常分别验收，末态直播正常不能补证之前各态。缺少静态压降测量条件时继续可独立完成的直播观察，画面正常也不代替真实码率效果。
- 本轮设备编码设置入口是“设备设置页下方 → 自定义编码参数”；9.139第二轮用户称“设备设置 → 自定义码率参数”，按该节核实当前入口标签与实际编码字段。直播清晰度仍在直播页选择。未定位时按 [设置页查找](workbook-contract.md#设置页查找与到底确认) 继续核实，不能用近名页面或设置页分辨率代替直播档位。短时浮层按 [连续操作规则](transient-controls.md) 定位与操作。
- 直播检查须进入同设备并等到真实出图，用多时点画面/播放反馈观察是否持续播放，记录花屏、黑屏、绿屏、卡住、持续加载等实际现象。按钮、单帧或“设置成功”不能单独证明画面正常；不凭空增加固定观察时长、听音结论或压降阈值。
- App 内直播录像与 ARTEMIS 操作录屏分开。业务要求录制视频时，实际定位录像控件、点击开始并确认录像计时/录制中反馈，以确认开始的时点计时，持续规定时长后实际点击停止并确认保存。按可靠时钟核验经过时间，有可取得媒体时再核验有效时长；开始、计满、停止、保存四项分别核对，不能把等待回执、模型耗时或自动化屏幕录屏当成本次录像。录像存在与可播放、画面判据分别确认，缺档、短片、未保存或时长缺证分别记缺项。
- 本轮12.14的录像按钮由用户确认位于直播页面右下角；这是当前App的定位线索，不是固定坐标。两条漏录运行的当前UI已有“开始录像”无障碍描述，虽然该节点资源ID为空，仍应按当前文字/无障碍语义及实际控件关联定位，不能因没有resource-id就跳过。按实际标签、图标和点击后计时/录制中反馈确认身份，不能把声音/静音开关、拍照或截图按钮当成录像；误点须重新定位并实际启动录像，未见计时或录制反馈不能直接进入业务等待。已实际确认同设备直播录像入口时可在后续段复用其语义位置，每段仍核对当前控件及录制反馈。
- “尚未尝试”与“实际受阻”分开：缺少可信默认、SDK/RTSP、码率分析、媒体提取或长期挂测条件，只保留其对应断言缺项；无实际阻碍时继续App内可做的录像定位、开始、真实计时、停止保存与其余组合。计划中写过录像、观察直播若干秒、因未尝试而称无法录制，均不算已完成或已证明受阻。仅在当前实际尝试及有限纠正后仍有明确控件、加载、状态冲突或工具障碍，或用户取消/实际预算终止时保留受影响段与具体反馈；不得把未验证清单当作省略可做动作的理由。
- 收尾前按状态/组合核对覆盖，保留原用例的其他有效动作、断言及收尾；单项偏差不提前停止独立可做项。不把新增要求叠加成重复录制或删去原有范围。未明确缩减集合时，改写只回填对应行，保留用户指定底稿的全部用例、编号、顺序、样式、辅助页与其他配置；用户明确只要本轮条目时按其指定集合输出。
## 9.101：两种码率模式与六段30秒录像
对应首轮运行 `26415f37-4870-4886-8735-a4f35061f9b4`、第二轮运行 `670f780a-513a-4236-b4a2-dd4f7e9d8252`。用户第二轮再次指出缺少直播30秒录像，因此本条须把六段App内录像写成独立必做阶段，不能只强化码率设置或直播观察。本轮已经给出具体目标，不再沿用“任选合法且不同于当前的码率”替代这些值。
第二轮实际因清晰度未确认而六段均未录，第23、24、25、42步已有“开始录像”无障碍描述但未实际点击，不能把这一缺口改写成录像能力已尝试且失败。后续按短时控件规则完成当前页清晰度定位与选择；旧运行未取得清晰度浮层证据，不能臆断为浮层曾显示后隐藏。当前档位已能确认时先完成其可做录像；某档确实无法确认时保留该组合未验证，继续其余可做档位及码率分支，不由一个未确认档位推定六段全部不可录。若经有限定位清晰度仍不能确认、但当前App录像入口可用，至少尝试一段原定30秒的开始、计时、停止保存，标明清晰度未确认而不计入任何指定组合；不为此强制重复六段未知档位录像。
| 设置阶段 | 本轮目标 | 直播页逐档录像 |
| --- | --- | --- |
| VBR | 平均值 2000、峰值 2300 | 标清、高清、超清各独立录制至少完整30秒 |
| CBR | 平均值 2000 | 标清、高清、超清各独立录制至少完整30秒 |
先记录原模式、字段、单位与开关状态，实际选择 VBR 并分别填写平均/峰值，核对必要保存及重新进入回读；不能只改一个字段或把目标值写进记录而未操作。保持该设置回到直播，依次核对标清、高清、超清选中及真实播放，每档实际点击App录像按钮、确认开始计时，持续录制至少完整30秒，再实际停止并确认保存后切档。完成 VBR 三段后，回到码率页选择 CBR、填写平均值2000并保存回读，再按标清、高清、超清完成同样三段，共六段。仅看直播30秒、切换三档或开启操作录屏均不算本条录像。CBR 未提供峰值字段时不编造该字段，不把 VBR 峰值继续当 CBR 验收项；字段单位与合法范围依实际页面记录，目标不可接受时保留该分支受阻，不擅自改数值或单位。
每段关联模式、实际设置值、直播档位、录制起止、实际计时及保存结果，能取得媒体时补核有效时长。收尾前按VBR/CBR各三档逐段检查四项动作，缺哪个阶段就补做仍可做的该阶段，不以“码率设置完成”覆盖六段录像。基础录制时长为 `6×30=180秒`，总预算还须覆盖设置、切换、加载和收尾；不从180秒直接推出总任务时限。保留原智能编码自动关闭及厂复默认分支的证据边界，按 [码率原范围](workbook-contract.md#用户确认路径与人工判定采集) 分别核验，缺少厂复默认依据不阻断本轮六段录像，不为补录擅自恢复出厂，也不追加12.14的实测码率或5分钟要求。
## 9.122：全部实际侦测关闭、AOV与退出后返回
对应首轮运行 `a80f256c-0b79-4496-8783-5a5ac5c230e2`、第二轮运行 `716e7b55-f60b-442b-b6c9-cc3d9fb8aeb4`。第二轮用户明确目标为AOV，不是智能编码。先在设备设置检查本设备实际存在的所有侦测/跟踪及 AI 功能，逐项读取并关闭、完成必要保存回读，再开启 AOV；不能只关移动侦测和声音侦测就宣布“全部已关”。
查找范围包括本轮用户列出的：人形侦测、移动侦测、声音侦测、人脸侦测、电瓶车识别、车辆识别、移动追踪、AI周界、AI设置等。它们是查找范围示例，按主设置页及真实子页核对；AI设置或 AI周界如为分组，进入关闭实际存在且可操作的相关算法/功能，并回读状态。近名项目不互相替代，不能把分组入口当成单一开关。找到的新侦测功能也纳入本条“全部实际存在”范围；未见项记录已查范围与尚未确认项，不臆造开关、不把未查写成不存在，不关闭与本条无关的安全或系统功能。
在“自定义编码参数”先读取并区分“AOV”和“智能编码”各自的标签、当前状态及所关联开关，实际操作明确属于“AOV”这一行的控件；不能凭相邻位置、颜色或已开启的智能编码推定AOV已开。AOV已开启则核验保持；关闭时开启AOV，并在必要保存后重新进入，回读同一“AOV”行确为开启，再退出App。AOV未定位时继续本页相关查找并记录缺口，不开启智能编码充当替代，也不把误点后的智能编码状态写作AOV生效。两功能身份未核实时不得声称本条前置已建立。
第二轮第24、26、27步实际点击相邻智能编码开关，智能编码多次变化而AOV一直关闭。两行共用 `setting_switch` 资源ID，单凭该ID或缓存坐标不能定位AOV；应将当前“AOV”可见文字与其所在行开关绑定，动作后回读同一行。该证据支持目标误定位与AOV未开启，不支持AOV开关存在产品故障；旧点击坐标不写入新提示词。
以实际退出并确认离开 App 的时点开始计时，保持不进入该 App 满60秒。设置页等待及App仍在前台的时段不算退出等待，也不能凭模型回合数或估计处理耗时推定已满60秒；退出状态实际持续期间经过的时间按可靠时钟计入；不为“退出”额外清数据、重装或默认强制停止，具体退出动作沿已确认安排。满60秒后重新进入 App、打开同设备直播，核实真实出图、持续播放及异常。分别记录侦测关闭覆盖、明确的AOV标签与开启回读、退出起止/60秒、返回直播结果；不能将智能编码开启记录移作AOV证据。
既有原文或用户仍保留的码率设置、真实动/静场景、不开直播挂测及对应生成视频“正常播放、无快播”继续作为独立范围；不凭本轮补充新增未指定码率。若仍需码率配置，在关闭侦测后、开启 AOV 前完成，记录 AOV 开启后的实际参数，不反复改码率干扰 AOV。60秒退出与直播检查是本轮必做的明确链路，不以“长期挂测时长未提供”省略；60秒也不自动证明其他原挂测条件或生成流通过。收尾恢复在直播结果观察后按既定安排执行。
## 9.137、12.29、12.3：每个规定智能编码状态都看直播
| 编号与对应运行 | 必须增加的观察阶段 | 仍独立保留的原范围 |
| --- | --- | --- |
| 9.137；`1feee1ea-4ae9-4233-b248-21c760575ad5` | 开启并回读后进入直播观察；再关闭并回读后再次进入直播观察 | 开关、可信默认及真实静态压降等原断言 |
| 12.29；`b659b7be-292c-4537-a7e9-6c90e30c7d18` | 开启态和关闭态分别观察直播花屏等异常，关闭后的观察完成再恢复 | 能力/配置项上报、默认、两态实际静态输出等 |
| 12.3；`fa5aef3c-93c1-4f16-88bf-f0d2a6c8cb76` | 开启并保存回读后进入直播观察花屏等异常 | 真实静态场景输出及关联效果标准；本条不增加关闭态 |
本轮9.137、12.29及12.3已确认“智能编码”就是原文的“静态码率压降”开关，不需寻找额外独立同名控件。12.3已回读智能编码开启时可核验并保持、继续直播和效果观察，不能因无另一个字面名为静态码率压降的控件将开启态判缺失；本字段映射限已确认设备/App，不推广为其他近名设置均等价。每一态的直播观察在该态仍生效期间完成。9.137、12.29不能仅在两次开关后最后看一次直播；12.3不能因为共用入口就增加关闭/默认或四组合录像。初始已开可核验保持并观察开启态，不为凑状态变化先关闭；继续按原顺序完成本条所需后续状态。真实测量和直播画面两类缺项分别记录，详情沿 [各条原断言](workbook-contract.md#用户确认路径与人工判定采集)。
## 9.139：参数变更后的两次重置提示分支
对应首轮运行 `dba4d0f0-baad-4962-83f9-ad26bb7fdc9d`、第二轮运行 `17086c4d-c92b-42fc-bb3c-31b5da99779e`。第二轮用户明确入口为“设备设置 → 自定义码率参数”。上轮同类入口称“自定义编码参数”；按当前实际标签进入，并以码率、帧率、I帧间隔及AOV/智能编码等实际编码字段核实是否为该目标页，仅文案差异不另跑通用AI或画面页，名称相近也不能单独证明页面等同。未定位时在设备设置列表按已确认路径继续查找，不以“画面与声音”“AI设置”或直播清晰度替代参数入口；实际入口名与用户线索分别记录，不倒填第二轮trace已走通。
第二轮实际进入的是设备能力集原始Config展示页，未进入可操作的自定义参数页。只读能力/配置文本只能提供实际展示的信息，不能代替本条参数输入、开关操作、弹窗触发及保存回读；发现进入该页后应返回设备设置沿目标入口继续，不在原始文本中寻找交互开关或直接结束互斥验证。
完成原码率/帧率/I帧间隔参数变更及自动关闭分支后，仍须实际开启 AOV 或智能编码触发恢复提示，不能在参数修改后结束。按原量词任选可用参数变更，不因本轮列出三项就强制全参数遍历。
两个功能分别在本次有效参数变更前置下开启。有可信默认时选合法非默认值；缺少默认依据时选合法且不同于变更前的值，实际变更、保存回读后继续弹窗及三字段核验，仅“恢复成默认”比较待核，不能因无法证明非默认而跳过两分支。参数变更触发保存/应用时，先读取当前自动关闭弹窗全文，再确认并完成保存、重新进入回读，不能先离页再回头核对已消失的提示。
随后分别开启AOV、智能编码，各自在离页前核对完整原预期弹窗“设置此功能，码率、帧率、I帧间隔设置将恢复成默认值”，记录实际全文及有无提示，再确认并回读码率、帧率、I帧间隔三项。前一分支已恢复参数时，应重新建立有效参数变更才做后一分支，不能在无变更时开第二个开关并认定重置提示已验证；实际参数变更无法保存或生效时才保留对应触发前置缺口。弹窗、开启状态及三参数默认比较分别验收；前段自动关闭提示即使漏写AOV或其他文案不同，也应保留该差异并继续后面AOV、智能编码各自恢复分支，不能以首个提示不符为由提前收尾。文案差异同样不阻断可做回读；可信默认依据缺少时读回值不冒称默认。保持 [完整互斥核验](workbook-contract.md#编码参数互斥与完整核验9139) 的参数修改前后态、自动关闭、直接关闭及收尾要求，AOV和智能编码不被误设成彼此互斥。
## 12.14：智能编码下四组合各录5分钟
首轮用户称“9.14”，但稳定运行 `5bbcedfe-efa5-4a71-8a6f-0751f4f89ece` 的 `sessions.initial_goal` 以 `【12.14】码率测试` 开头，指定底稿也为12.14；用户已确认优化原12.14并保留编号。第二轮对应运行 `d064bf8c-0118-46ed-8d8b-05de415dd8c5`，用户再次明确必须在直播页录像，按钮位于右下角；该位置作为当前App线索按当前布局核实，不写固定坐标。
第二轮第15、16、29步实际页面已有“开始录像”无障碍描述，但四段均未开始；第16步点“相机”后出现预览缩略图，属于拍照反馈，不是录像开始。该轮仅在自定义分辨率面板看到960×540、2304×1296、2560×1440选项，未选直播高清/超清，不能据此声称直播档位切换已完成。不能以码率分析条件不足或时长等待尚未执行推导App内录像不可做。新提示词须落到实际录像动作和四段时长，未尝试、未录、未保存分别保留，不把历史业务结束状态等同录像覆盖完成。
开启智能编码并保存回读，在该设置页核对码流/编码格式切换，严格按以下顺序完成四段：`H265×高清 → H265×超清 → H264×高清 → H264×超清`。先选择H265并回读，回同设备App直播页选高清，等真实出图，在右下区域定位实际录像按钮并点击；核实不是声音或拍照功能，确认本段录像计时/录制中反馈后开始可靠计时，连续完整300秒，再实际点击停止并确认保存。完成后再切超清并重复完整动作。两段H265均结束后回设置页切H264、保存回读，再在App直播页按高清、超清分别完成同样的开始、完整300秒、停止保存，共四次App内直播录像。四个组合逐段关联实际codec、档位、智能编码状态、起止、时长及保存结果，不能仅查看切换菜单、直播播放5分钟、把一段复制为四段或录制中途切档。
本轮明确要求在App直播页完成上述四次录像。RTSP等实时码流采集只可补充真实码率定量分析，不能代替App内业务录像，也不能因外部码流可采集而跳过App录像的开始、300秒、停止保存；缺少分析/提取能力同样不阻断可做的四段App录像。每段真实等待是业务动作，尚未执行等待不能写为等待受阻，模型处理耗时或一次短等待不证明已录满300秒；录像仍在持续且无实际障碍时，按可靠截止时间继续剩余时长，不能切档即收尾。开始、真实计满、停止和保存分别确认后才标本段完成；保存失败与时长缺证分别保留，不以“已录制”笼统覆盖。
当前已确认的直播档位先录，某个切档入口或组合受阻不吞掉其余可做段。经有限纠正仍无法确认任何清晰度、但实际录像入口可用时，尝试一段原定300秒的App录像，标明档位未确认，不计入四个指定组合；其余切档缺项保留，不为补覆盖重复录四段未知档位视频。
复用 [四组合录制方法](workbook-contract.md#编码组合录制与码率判定1214) 中的实际选中、媒体时长核对、素材来源及预算规则时，以此本轮App录像范围为准；编码或清晰度切换后核对智能编码仍生效，发生冲突时记录，不用固定码率代替。基础业务录制已1200秒，按真实总流程保留足够余量及已有合理配置。本条原12.14的全部像素档阈值、峰值及静/动态总量判据继续沿原范围独立保留；四段录像不自动代表其全部通过，也不因本轮补充就缩减原范围。
## 12.24：云回看左下日期与最近7日告警抽查
对应运行 `4eeb25f7-0cf3-4872-b2f2-7fd0bdbb5eef`。最近7日云告警视频抽查是本轮明确必做项，不能只看普通时间轴、告警列表或“一天快放”。确认同设备云回看，在本轮已确认的左下角日期入口选择日期，按选中反馈回读日期、等待该日数据加载；不固定像素坐标，也不从旧截图沿用定位。以可靠当前日期/时区列明最近7日范围，未另指定时按当天及前6个自然日，当天只查已过去时段，不等待未来七天。
逐日查看可用告警记录，在实际有告警的日期抽样选择告警视频并实际播放，关联日期、事件类型、事件时间/片段及播放结果，检查是否正常出图和持续播放。按实际分布覆盖不同日期，不因某日无告警就虚构样本，也不以同一天多个片段充当七日覆盖；用户未指定样本量时按可用记录合理抽样并说明已抽查数量/范围，不把抽查扩成必须播放七天全部视频。日期无记录、保留不足、服务不可用或播放失败分别记录；空列表不证明应有事件无丢失，正常时间轴也不证明告警视频可播放。
保留 [原最近七日云/卡时间轴检查](workbook-contract.md#最近七天云存卡存空洞检查) 及原7×24小时、每日10事件、无丢失/可播放范围，各自记录覆盖与待核项；新增云告警抽查不取代双存储历史空洞检查，也不要求无历史的新挂测作为开始抽查前置。完成可做的日期选择与抽查后再按本条约定收尾。
## 12.28：卡回看和云回看分别调到12H刻度
对应运行 `36d12ee1-1289-430a-8fba-f103e75bff85`。实际进入同设备卡回看、云回看，两侧均需使用页面下角实际可见的放大镜缩放控件，将时间轴显示跨度调至 `12H` 并核对显示；本轮未确认左右位置，按当前页面识别，不写固定坐标或盲点次数。每次操作后观察刻度/跨度反馈，必要时在实际可用的增/减控件之间调整；若界面用其他标签，记录实际刻度，未达到12H时不声称完成。切换存储后重新确认，不能从云侧12H推定卡侧同样生效。
`12H` 是显示尺度， [最近十二小时窗口](workbook-contract.md#最近十二小时云存卡存空洞检查) 是实际检查时间范围，两者分别满足。调到12H后仍需确认选中日期、窗口起止与轨段已加载，按同一请求窗口检查两侧，跨日分别选日并覆盖交集；仅见12H标签或一屏正常不等于最近12小时全部已查。保留原空洞颜色/应录制解释、逐洞播放反馈，以及动态高码率负载与至少12小时无重启/掉线等独立判据。缩放受阻时记录控件、实际跨度和已查/未查范围，不用存储卡容量页代替、不反复改侦测来冒充历史负载。
plugins/codex/plugins/artemis-case-prep/skills/artemis-case-prep/references/project-feedback.md
+79
View File
@@ -0,0 +1,79 @@
# 既有项目反馈与专项修订
本文保留桌面优化版记录的既有移动爱家项目反馈。“本轮”、用户确认、运行 ID、68条集合、V6/V7底稿、雷电模拟器、移动爱家 V99.0.0、长虹SC52034、指定参数和桌面交付位置，均指该来源项目的记录。仅在当前用户明确沿用相同项目/任务表，或当前原文与确认资料可明确对应时采用相应专项；不能把附件里的旧对话当作本次新确认，也不把仅编号相同视为同一用例。
仅更新、合并本 skill 不触发 Excel 改写、桌面写入、测试派发或历史结果回写。用户实际要求修订任务表时，才按当前指定或最新已交付底稿回填；当前请求的范围、路径及已确认资料优先。通用收尾遵循 [完成与收尾](workbook-contract.md#用例完成检查与收尾) 及主 skill：移动爱家保留强停规则，不因本参考的页面操作省略进程核对。
以下是来源项目的反馈与规则，保留其业务范围及证据限制；合并文件本身不表示已重新读取原 trace 或完成设备复测。
用户要求复盘已有任务并重出提示词时，沿稳定 batch ID、session/trace ID 与本条原文建立对应，读 [已有任务表复盘修订](workbook-contract.md#已有任务表复盘修订)。逐条修正有证据的范围扩大、定位等待及前置假设，保留有效规则、原断言和用户的执行安排。用户新确认的页面路径可用于本轮提示词，注明来源，不冒充旧 trace 已验证；涉及本轮移动爱家路径或人工采集时，读 [用户确认路径与人工判定采集](workbook-contract.md#用户确认路径与人工判定采集)。用户明确改为指定画面截图、操作录屏、日志地址/文件采集或自定义图片上传，结果人工判断时，按新范围编写操作与交付要求，人工结论保留待判，不套用首次全自动筛选规则排除整条。这些指定内容是该条的验收交付物，与前文不写入提示词的通用证据归档要求分别处理；操作录屏须以受支持的单条任务配置实际开启，不能仅写提示词或用App内录像代替。全量审阅稿与按历史执行完成筛选的任务表分别标识；暂不适用记录移出“任务”页，不能因重写或历史 completed 就认为业务已通过或条件已解决。
**单条复盘只改对应行，默认交付Excel任务表副本**：当用户要求修订并重出既有任务表时，按该项目已确认的格式，以用户指定或最新已交付的七列Artemis任务表为底稿，只回填受影响用例的完整提示词及确有必要的单条配置；主交付为保留原表结构和用例集合的新版`.xlsx`，按“artemis-tasks(调试版)_设备_本次优化内容_条数V版本_日期.xlsx”命名并保存桌面。保留原编号、标题、顺序、环境、原动作/判据、其他条目、辅助页、样式及批注，不覆盖底稿，不把“只改对应用例”解释成默认仅交TXT/JSON或需要重写全部用例。上次Excel交付后已定稿且尚未回填的相关修订一并准确带入，不回退成旧提示词。TXT/JSON仅在用户另行指定或作为附加资料时交付；用户明确仅要单条Excel时才缩减行集合。
仅当用户明确要求对既有68条全量重新审阅、应用skill或改写时，先按 [本轮68条重出与覆盖核验](workbook-contract.md#本轮68条重出与覆盖核验) 沿用用户指定或本轮最新已交付的68条集合（本次重出底稿为V6）、已确认环境及人工交付范围，逐条应用本skill相应规则；不重新取历史完成任务并集，也不要求重复确认已知资料。本轮明确删除4.12、9.61、12.8、13.12、16.2、1.35、23.33；只从本轮任务与配套分类移除，保留仍适用的通用知识和历史复盘。输出附技能来源与逐条覆盖核验，不能仅改版本名或在所有提示词末尾统一追加一段而声称已完成整合。
本轮3.3/3.6新增失败已确认使用V7正文，早帧/原录像均已显示浮层，执行端只交较晚隐藏图导致首次入口未定位。按 [短时浮层与连续操作](transient-controls.md) 使用同动作较早图识别入口、当前末帧核布局、目标隐藏后在同一受支持序列重新唤出并点击；早帧不当当前状态，双击不替代两个目标的连续操作。只写“快速点击”或在同一隐藏图反复询问Explorer不能补足首次发现；技能文字、执行层早帧实际传递和设备复测分别验收。
本轮4.11转动噪声用例按用户补充的 [四向长按与操作视频](workbook-contract.md#云台四向长按与操作视频411) 执行采集：上、下、左、右各真实持续按住5秒，逐方向松手并观察，不能用四个短点或单方向1800ms替代。单条配置开启操作录屏；缺少可靠声音或场景比较证据时保留原噪声判定待核，仍完成可独立执行的四向动作和视频交付。四方向动作及视频缺项不能被“执行完成”掩盖，不将此要求推广为所有用例开启录屏。
本轮6.5“回放不同清晰度的云回放”按 [直播逐档五分钟与对应云录像](workbook-contract.md#直播逐档五分钟与对应云录像65) 明确阶段依赖：云存状态未核实时实际进入同设备云回看，核类型/日期并尝试播放过去片段，记录可访问范围或明确限制；此独立探查可先做，清晰度局部受阻也不能跳过。旧片段不代验本次新录制。核实直播清晰度菜单与实际选中，每档连续播放300秒并生成起止表，之后才核查对应新云录像。整屏中心不能当视频中心，视频外/相机误点须重新定位纠正；画面内容模糊只影响相应画质判据，不能单独阻断可做切档和计时。旧云录像、生命周期completed或仅查看菜单均不补足本次必做动作。
本轮7.4“回放不同清晰度的卡回放5分钟”按 [本次切换点定位与操作视频](workbook-contract.md#卡回放本次切换点定位与操作视频74) 编写：直播可用档各播放300秒并记录切换边界；选中高清等档位后须实际建立本档t0、使用受支持等待按真实剩余时间继续，未做等待不构成等待受阻，不能切档即强停。实际进入卡回看后必须拖动时间轴到本次各档及切换前后，回读选中时刻并播放；没有先见录像条不构成禁止选时的理由，推广卡也不代表卡时间轴不可用。按用户新范围仅采集操作视频，音频原判据保留人工待核，不阻断选时和可用档位；本条配置开启record_video、关闭analyze_video，保留Flash和3600秒预算。卡录像随直播变码率或固定码率均可，不强加变化策略。
本轮3.2“设备缩略图展示”按 [缩略图顶部下拉与直播返回更新](workbook-contract.md#缩略图顶部下拉与直播返回更新32) 分开编写两条观察链：在实际缩略图模式记录同设备目标基线，先回到并确认列表最顶部，再独立执行一次下拉刷新，核实触发及完成反馈后重新定位目标比较；从列表中部向下滑、看见首卡或手势回执均不证明刷新。触发仍未证实时保留手动刷新未验证，继续独立的进入直播、返回列表后更新检查；返回更新不能补证之前下拉已触发，也不要求新缩略图与某张较早保存的直播帧逐像素一致。缺少刷新前提证据时，不因旧图未变直接判产品失败。
本轮设备型号用例 9.2 按上述用户确认路径，先点击目标设备“设置”页最上方的设备图标，再从打开的实际页面读取型号字段，与已取得的独立厂商型号按本条既定规则比较；不只向下遍历设置列表，也不以设备昵称或图标外观代替型号。
本轮9.32休眠用例按 [休眠直播检查与唤醒恢复](workbook-contract.md#休眠直播检查与唤醒恢复932) 编写：确认休眠开启后，必须保持该状态实际进入同设备直播，读取休眠提示及推流现象；观察完成或确有局部受阻后，实际唤醒或在设置关闭休眠并回读，再进入直播确认恢复播放。开关关闭及“设置成功”只证明设置反馈，BACK到设置外层不算进入直播。某项偏差、智能喇叭/智话或硬件分支依据缺失不阻断独立可做的直播检查与唤醒；本次末态为已唤醒，不为恢复初始值重新开启休眠，不串入9.33实体遮挡动作。
本轮9.31“设备支持按需上传日志”按用户新确认的 [自动维护最近日期检查](workbook-contract.md#设备自动维护最近日期检查931) 执行：在目标设备设置页回到最顶部并实际点击设备图标，进入信息页后对真实“设备型号”连续点击5次，核实开发者模式反馈，再进入“设备自动维护配置”读取“最近维护日期”。本次只判断是否显示日期，原维护周期、重启/日志上传、跨日与离线等判据保留为来源待核，不修改维护/日志参数或触发维护。可读字段有日期、已读无日期、入口/加载受阻三种情况分别记录；有日期不等于原维护和日志机制全部通过。
本轮 9.69 日志用例按用户确认的“设备设置 → 顶部设备图标 → 详情 → 设备日志管理”采集：记录初始档位，实际调整两次，每次回读并取得、关联完整日志获取地址；可下载文件由宿主按实际能力留存。日志等级与 App 档位的一致性保留人工核对，不以内部数值映射或自动正文核查缺失阻断采集；采集完成不等于业务通过，具体写法见上述参考。
本轮 9.21 设置项检查，按上述参考先读取原七组升级前设置，再回到同设备“设置”打开“固件升级”，检查是否有可用新版本。保留未读配置的覆盖缺口，同时继续可独立完成的版本检查；不能在尚未查询前就以没有 OTA 完成证据或未人工提供升级包结束。版本检查与真实 OTA 后的设置保持比较分别验收。
本轮 13.13“固件包版本校验”按用户确认，在目标设备“设置 → 固件升级”读取“当前版本”，该值就是本条的固件包版本，不要求界面标签字面写成“固件包版本”。沿 [用户确认路径与人工判定采集](workbook-contract.md#用户确认路径与人工判定采集) 仅核原三段纯数字、每段最多5位，保留版本原串与前导零；不追加与预期版本相等或实际升级断言。历史 abeb226f 已走通此路径，按确认口径复核格式通过，原失败属于字段含义误判。
本轮 9.101 码率用例按 [本轮编码与回看补充](encoding-playback-feedback.md#9101两种码率模式与六段30秒录像) 在“自定义编码参数”设置 VBR 平均2000、峰值2300，保存回读后到直播标清、高清、超清各独立录30秒；再设 CBR 平均2000、保存回读，重复三档各30秒，共六段。第二轮再次漏录，提示词须把每段“实际点击App录像开始并确认计时 → 真实录满30秒 → 点击停止 → 确认保存”写成必做阶段，直播观察、操作录屏或未尝试不能算录像完成或受阻。原智能编码自动关闭及厂复默认分支保留，缺默认依据不跳过可做录像，不擅自恢复出厂。具体数值只适用于本条，不再用任选码率代替已确认目标。
本轮 9.122 按 [全部侦测关闭、AOV与退出后返回](encoding-playback-feedback.md#9122全部实际侦测关闭aov与退出后返回)，检查并关闭设备实际存在的全部侦测/跟踪及相关AI功能，包含主设置页与AI周界、AI设置中的实际相关开关；不能只关两项。再在“自定义编码参数”核实“AOV”标签及同一行开关，实际开启AOV并保存回读，不能开启相邻“智能编码”作替代或混记状态。退出App后真实等待60秒，返回同设备直播观察。原仍适用的码率设置、不开直播挂测及对应生成流另列阶段，60秒退出与直播不替代长期断言，未具备长期条件也不省略本轮明确链路。
本轮 9.133 分辨率用例按用户确认路径，在目标设备“设置”页下方打开“自定义编码参数”，先查看实际分辨率、当前选中值及可选项；不再以“画面与声音”或直播清晰度标签代替入口及数值。原用例的按设备支持档位切换、保存回读及切换后直播音画检查继续保留，查看完成不等于整条通过；不串入码率修改、AOV 或智能编码互斥要求，细节见上述参考。
本轮 9.137 智能编码开关在“自定义编码参数”读取初态、按原顺序开启和关闭并分别保存回读；每一态仍生效时都进入同设备直播观察画面，不能开关均结束后只看一次。原默认、两态实际静态输出及压降判据保留，与新增直播观察分别验收；详见 [每个智能编码状态检查直播](encoding-playback-feedback.md#91371229123每个规定智能编码状态都看直播)。
本轮 12.29“静态码率压降开关（暨‘智能编码’开关）”到设备设置页下方“自定义编码参数”操作，沿原步骤保留能力/配置项上报、可信默认和开关两态真实静态输出；开启后、关闭后分别进入同设备直播检查花屏等异常，再进入下一态或恢复，详见 [每个智能编码状态检查直播](encoding-playback-feedback.md#91371229123每个规定智能编码状态都看直播)。缺实测依据不省略可做直播观察，画面正常也不代替压降效果；不串入四组合录像、固定5分钟、AOV或互斥专项。
本轮历史记录编号12.3“静态码率压降效果测试”沿“自定义编码参数”核对并开启智能编码、保存回读，开启态进入同设备直播检查花屏等异常，再按本条真实静态输出及已取得的关联规范判压降效果，详见 [每个智能编码状态检查直播](encoding-playback-feedback.md#91371229123每个规定智能编码状态都看直播)。本条不增加关闭/默认或四组合5分钟；原定量标准缺失时保留测得数据和判据缺项，不编造比例。模型反复超时按执行方异常处理，不归为设备效果失败。
本轮 9.138 AOV 开关同样到设备设置页下方“自定义编码参数”操作，读取初态，按原步骤开启、关闭并分别保存回读。供电类型及可信默认起点只用于判断常电/低功耗的原默认分支，缺少时保留默认未验证，继续可独立执行的开关核验；不从室内云台类型猜供电类型，不串入9.122的码率修改或挂测要求，细节见上述参考。
本轮 9.139 按 [编码参数互斥与完整核验](workbook-contract.md#编码参数互斥与完整核验9139) 从第二轮用户指定的“设备设置 → 自定义码率参数”进入；若当前显示上轮名称“自定义编码参数”，核实实际编码字段与目标页，不改到通用AI/画面入口。保留原“任选一项”参数变更及自动关闭；后续必须分别在有效参数变更条件下开启AOV、智能编码，核对完整弹窗“设置此功能，码率、帧率、I帧间隔设置将恢复成默认值”并回读三参数。两分支不能共用已重置的前置，不因提示偏差提前收尾；详见 [重置提示分支补充](encoding-playback-feedback.md#9139参数变更后的两次重置提示分支)。原关闭、可信默认等判据保留，不将两开关误设为彼此互斥。
本轮 12.6 直播时延用例仍要求实际连续播放满30分钟后测量 `t≤2s`。按上述长时规则预留单条预算，以确认直播实际播放正常的时点计时，按真实截止时间分段等待并检查播放状态，不从任务启动起算，也不在已有播放时间之后机械追加完整30分钟。独立采集至呈现的时延测量方法须落实，不能以OSD与系统时钟表面差值代替；等待完成、直播持续及测得时延分别验收。
本轮12.14已按用户确认保留原编号（首轮曾称9.14）。按 [四组合录制补充](encoding-playback-feedback.md#1214智能编码下四组合各录5分钟) 在“自定义编码参数”开启智能编码并保存回读，依次完成 `H265×高清 → H265×超清 → H264×高清 → H264×超清`。每段都在同设备App直播页按当前布局定位右下角实际录像按钮，核实不是声音或拍照控件，点击开始并确认计时，真实录满300秒后点击停止、确认保存，再切下一组合；四段共1200秒，另预留切换、加载、保存、分析及收尾余量。RTSP采集或操作录屏不能替代App录像；未尝试录像不算受阻，缺分析/提取能力不跳过仍可做的四段。按 [码率测量与判定](workbook-contract.md#编码组合录制与码率判定1214) 逐段关联实际codec、视频尺寸、智能编码状态及真实素材，计算平均视频码率并按实际像素档匹配原阈值；均值、峰值及静/动态总量分别判定，原断言缺项单列，不合并成整条通过或扩成全部五档遍历。
本轮 12.24 按 [最近7日云告警抽查](encoding-playback-feedback.md#1224云回看左下日期与最近7日告警抽查) 在云回看左下日期入口逐日选择并回读最近7日，抽查实际告警视频并播放，不用普通时间轴或一日多片代替多日覆盖。原 [云存卡存空洞检查](workbook-contract.md#最近七天云存卡存空洞检查) 与7×24小时、每日10事件、无丢失/可播放分别保留；纯白/灰彩口径须结合应录制区间，无记录与未查分别报告。先查既有历史，不等待未来7日。
本轮 12.28 按 [双存储放大镜与12H刻度](encoding-playback-feedback.md#1228卡回看和云回看分别调到12h刻度) 分别进入卡回看、云回看，操作页面下角实际放大镜缩放控件并确认时间轴为12H。显示尺度与 [最近十二小时检查窗口](workbook-contract.md#最近十二小时云存卡存空洞检查) 分别核验，按同一窗口和跨日交集检查，不能只见12H就宣布范围已覆盖。保留空洞/回放和原负载、至少12小时无重启掉线判据，缺新挂测不阻断回看，容量页不能替代卡回看。
本轮 9.65 logo 水印用例，按 [提示词与决策](workbook-contract.md#提示词与决策) 保留“确认支持与初始状态 → 开启并核验各指定渠道 → 关闭并核验”的顺序，分别核实可信默认、实际开关和视频水印，不预设未走通的入口。多个渠道须对应同设备与开关生效时段，缺项分别保留，不能把模型调用异常写成水印功能失败。
本轮室内云台机的夜视画面/距离取图，按上述参考的设备能力分支编写：未见“智能夜视”且已核实夜视页的“自动”选项时，可保留或选择“自动”继续指定取图；提示词须明确不得关闭夜视或开启全彩模式作为替代，实际模式如实记录，智能夜视专项断言与人工距离结论分别保留未验证/待判。
本轮人形侦测告警及其事件视频用例，按 [人形侦测与告警判断](workbook-contract.md#人形侦测与告警判断) 编写：先到目标设备“设置”查找人形侦测，未见时说明可能不支持、需人工核对；找到后先读启用状态，再按本条范围判断告警。不能以告警分类或历史列表未见“人形”代替设置核查，也不将“查看是否开启”扩成未经授权的开启操作。
**16.1“人脸抓拍逻辑”优先采用用户2026-10-21的新口径**：按 [第16部分入口与16.1例外](workbook-contract.md#第16部分云化ai算法范围与入口)，先只查同设备设置主页面的“人脸侦测”；主列表加载并完成必要查找后，有入口即按用户口径支持本条端侧算法，无入口记录“设备不支持端侧算法，需人工判断”。未加载、未查完或滚动受阻不是“没有”。入口灰色、关闭或标“云存储专属”仍属有入口，但不证明启用、服务可用或抓拍效果通过。支持后进入已找到的人脸侦测页，只查看本条原逻辑/模式及核验原抓拍判据，不新增开关、参数修改或其他云化指标；无真实场景/图片时保留效果未验证，不进入AI设置、AI周界等另找替代算法，历史记录不倒填通过。
其余原第16部分云化AI用例继续按 [云化AI算法范围与入口](workbook-contract.md#第16部分云化ai算法范围与入口) 到目标设备“设置 → AI设置”核对本条对应算法，只有该入口内的算法才计入云化AI。对这些条目，主页面的端侧“人脸侦测”即使标有“云存储专属”，也不能替代目标云化算法或证明其支持。未见时按设置页及AI列表实际进展继续查找；合理查找后仍无对应入口/算法，说明可能不支持并保留人工核对及未查范围，不断言不支持、不改测端侧功能。找到入口与效果达标分别验收，原适用条件、样本和指标仍按各条保留；16.1例外不改变16.10、16.75、16.124及9.122的既有路径与范围。
本轮16.10用户补充须先确认并开启“人脸-AI”：在上述AI设置内定位实际对应的云化人脸算法，读取初态，关闭时开启并核对必要保存/回读，已开启则保持；不以翻转视频源开关代替人脸AI启用。随后保留真实倒装及翻转生效期间的原效果检查，关联本次有效状态下的人脸上报图片和云录像，不能用启用前的旧声响事件取代，具体按上述参考的16.10分支编写。本次开启要求限该条补充，不将其他仅查看的16.*用例统一改为开启。
本轮AI车辆识别（含16.75）及AI电瓶车识别（含16.124）的AI识别，均按用户确认属于各自目标算法，不能由“AI周界”中的汽车/非机动车目标、区域入侵、越界侦测或普通移动侦测代替，也不再将这些功能作为目标算法的候选入口。先在设备设置页沿上述AI设置路径查找本条对应算法开关，通用“车辆识别”不自动等同电瓶车识别；充分查找后仍未见，说明可能不支持该算法、需人工核对，保留已查/未查范围，不判确定不支持或算法效果失败。具体按上述参考的车辆、电瓶车分支分别保留本条原动作与判据，经确证共享的参数/控件仅按实际范围复用，不证明算法身份或已启用；16.75仅核原真实区外车辆负向，16.124仅查看电瓶车画框、侦测开关、灵敏度和区域四项支持，不把两条条件互相套用或追加效果指标。
本轮 8.30 声音告警用例，按用户已明确的 [声音侦测开启与两分钟后检查](workbook-contract.md#声音侦测开启与两分钟后检查) 编写：先进入目标设备“设置”，开启声音侦测并确认生效；已开启则保持。以本次确认时点起计满2分钟，再查询同设备对应时段的告警。声音侦测开启、告警产生与原文哭声视频质量分别核验，不只翻查旧告警，也不把缺少声源证据当作省略开启、等待和查询的理由。
本轮1.14“7天挂测设备异响检查”按用户补充的 [声音侦测状态与最近七天告警](workbook-contract.md#声音侦测状态与最近七天告警) 编写：先到同设备“设置 → 声音侦测”查看是否开启，保持原设置，再逐日检查最近7天已有声音告警，记录实际日期、夜间记录和已查/未查范围。当前状态不证明七天历史状态，一条告警或空列表不代表七天结论；“较大声响”标签也不能单独证明设备自身异响。保留原第二监控设备及连续七天含夜间的条件与待核项，不因缺少这些资料跳过可独立查询的历史；本条不套用8.30的强制开启、2分钟等待，也不串入云卡空洞检查。
本轮23.28“更换已应用自定义桌面”按用户新确认的 [自定义图片上传与人工核对](workbook-contract.md#自定义图片上传与人工核对) 执行范围编写：在同设备“设置 → 桌面显示 → 自定义”完成图片上传，确认本次新增图片在App列表中可辨、稳定留存，即算本轮自动上传执行完成；选择自定义桌面无明确反馈时记录现象并交人工核对，不因缺应用按钮、“使用中”或实体屏幕证据反复重试、判上传失败。原A/B/C切换及实体显示、无重启离线等结果保留人工待判，不再作为本轮上传完成门槛；不为补齐旧门槛另切系统主题或删掉待核图片，按既定保留/恢复及App收尾安排交接。
plugins/codex/plugins/artemis-case-prep/skills/artemis-case-prep/references/transient-controls.md
+56
View File
@@ -0,0 +1,56 @@
# 直播短时浮层与连续操作
用于准备或修订直播清晰度、全屏及声音开关等用例，以及复盘“点击画面后未见功能”的执行记录。只在本条需要相关控件时使用；设置页等持续页面仍按其实际加载条件等待。本技能不启动设备、不执行连续点击、不修改观测器或后端配置。
## 编写任务中的操作说明
1. **先核对落点并唤出。** 按当前画面辨认真实视频边界；目标当前不可见且尚无本次唤出证据时，在画面内无按钮区域单击一次唤出控件，再查看该动作的观测。目标当前已显示时直接操作，不额外单击把它隐藏。避开下方录像工具栏、抽屉拖柄和云台面板。动作说明写“点视频”不证明实际命中；只有面板收起/展开时先纠正定位。全屏、横竖屏、抽屉或布局改变后重新识别。优先采用执行端实际支持的文本、ID等定位；坐标仅使用当前布局已验证的位置，不复制历史任务坐标。
2. **首次发现要利用同动作早帧。** 唤出后同时核对执行端实际提供的较早动作后画面和当前末帧，从可见图像辨明清晰度文字、全屏或声音控件的位置与作用；UI树没有“高清”不否定图像里的“高清”。较早画面是已发生的短时证据，不是当前状态，也不提供当前元素索引。它能补齐首次入口定位，不能因末帧已隐藏而丢弃，或只在同一张隐藏末帧上反复询问Explorer。没有早帧时按下述取证分支核实，仍不明则保留入口未定位，不能靠双击或猜坐标补足。
3. **定位后在当前布局内完成连续操作。** 将较早画面与当前末帧核对为同设备、同视频边界、方向、工具栏及面板布局后，才把该入口用于当前布局；横竖屏、面板或页面改变后重新定位。当前已显示目标时直接点目标，避免再点画面将它隐藏；当前已隐藏且布局仍一致时，在一个实际支持的短序列内完成“唤出浮层 → 点击已确认目标入口”，中间不采完整UI树、不等待下一轮模型。当前Flash实际开放 `click_sequence` 时应使用它；两个模型回合的单击、同点 `times=2` 双击，都不能代替两个不同目标的连续操作。未验证双击语义时不以双击试代替全屏或清晰度入口；其他执行模式只采用其真实支持的连续动作能力，不发明工具或参数，不套历史截图的元素索引，也不在布局已失效时照搬位置。
4. **等待业务反馈。** 点击入口后，以菜单出现、全屏状态、声音图标状态等本条可观察结果为继续条件。清晰度用例须按原文选择实际档位并核对选中反馈和所需播放结果；菜单打开不等于切换成功。目标已经可见时直接操作，不再额外点击画面导致浮层被切换隐藏。
5. **有限恢复。** 已确认的浮层隐藏后，可依据仍有效的布局重新唤出并连续点击。若再次因相同的慢观测错过窗口，停止这一循环，交执行方核对能力和观测耗时；不靠反复点画面、延长等待或增加步数解决。仍不能操作时只记录本条未完成范围，不转去无关设置页泛查，也不推断功能不存在。只有本条确需其他入口且有实际线索时才探索相关路径。
若本条只要求在某档位持续播放（如3.3），本次当前画面已明确显示所需“高清”时可确认并保持，不为确认增加无意义的改档再改回；同动作早帧可作为该时点的档位证据，须结合之后是否改档、是否仍为同设备播放核实适用范围，不能把任意历史标签当当前状态。3.6等原文要求往返切换的用例仍须实际完成各次切换，初始已高清不免除后续操作；3.3的有效10分钟及质量观察也不因入口曾显示而完成。
可拼入已补齐环境、原步骤和判据的正式提示词的动作段示例（不是完整可派发任务）：
> 在当前视频内唤出控件，首次从同动作提供的较早画面识别清晰度入口，同时用当前末帧核对设备、视频边界和面板布局。早帧出现而末帧隐藏表示曾显示；布局仍相同时，用实际支持的 `click_sequence` 在同序列中重新唤出并点已确认入口，不拆成两个模型回合或改成同点双击。目标当前可见则直接点；布局变化重新定位。打开菜单后按本条原要求核对实际档位及播放，较早画面不作为当前元素索引或完整业务通过依据。
只取本条适用部分；声音用例不追加清晰度切换，全屏用例不追加听音或画质判断。工具配置、观测日志和通用证据归档不拼入每条任务正文。原用例明确要求的业务时长仍须实际计时，不以模型处理时间代替。
## 执行方的取证与诊断
以下供后续获准执行的 Codex 交接和只读复盘使用，不是本技能的设备执行步骤，也不是保证提示词可控制底层观测器的承诺。
- 对齐同一 trace 的实际动作与落点、最早有效画面或已有录像、后续截图及返回时点。条件允许时保留点击后的首张有效截图，并记录后续隐藏状态；工具只返回末帧时明确限制，从已有录屏补证，不声称未保存的首帧已取得。不为捕获浮层重复触发录制、通话等业务动作。
- 对短时控件分别核验“曾显示”与“后续目标操作完成”；不要求整幅直播画面稳定后才认可浮层。多轮稳态采样可能丢失瞬态，提示词无法修复执行器行为；超出能力时记录限制并交接所需观测改进。
- 先核执行器是否已经采到早帧、但只把最终稳定帧传给模型。此时仅追加“快速点击”仍不能让首次未知入口被发现。执行层应保留当前末帧与当前元素，另把同动作的最早有效画面作为明确标时序的历史证据提供给实际决策端；不得直接将早帧替换成当前状态。发现信息不仅要写进日志，还要核对Flash/Pro实际消费的多模态上下文；只保存文件或发一段“请看早帧”文字不等于模型已看到图像。早末帧整幅图像感知哈希接近也不证明短时控件相同。
- 区分动作开始、截图采样、图片入库、状态返回及模型决策时间。入库时间不能冒充精确采图时刻，整段耗时也不能全部归为模型延迟。截图与 UI 树可能采于不同时刻，不能拿晚时点的空元素列表否定录像中的早时点显示。
- 核对原始 Flash/Pro 配置和 Runner 日志；摘要标签不一致时保留差异，不凭标签选择修复方式。既有录像按真实时间戳用 FFmpeg 等可靠工具抽帧；变帧率录像的 OpenCV 按时间定位须先验证时间映射，不按帧号和名义帧率直接推定时刻。
- 观测异常、任务工具报错或设备问题先按 ARTEMIS 工作流调用 `mobile_diagnose`。日志出现 helper 不可用、UIAutomator2 停止/恢复、后端回退或多轮观测时，记录它们与操作窗口的时间关系；不能把本次相关性推广成所有失败的根因。helper 缺失只是可选能力降级时，不因它单独判整机阻塞，也不反复诊断同一可选项。
- 构建或部署 helper、调整后端恢复策略或修改默认配置，交执行方按实际诊断和授权另行处理。技能更新不代表这些修复已完成；不自动全局开启录屏、切换模型/执行模式、增大超时或重提原业务任务。需要新增录屏时遵循当前任务的配置与授权，不能事后补拍冒充原执行证据。
| 证据 | 本条应保留的结论 |
| --- | --- |
| 实际落点在拖柄/工具栏，只有面板变化 | 定位未成功；重新定位后有限纠正，不能写成已点视频仍无控件。 |
| 录像或早帧明确出现浮层，末帧已隐藏 | 唤出成功；若没完成入口点击，则记录短时交互未完成，不再写“未弹出”。 |
| 仅有较晚截图或晚时点 UI 树，缺少即时画面 | 未取得足以判定是否弹出的短时证据；不确认为 App 缺陷。 |
| 仅有 tap success / dispatched 回执 | 只证明调用结果，仍需实际界面证据；不直接记业务成功。 |
| 菜单已打开，但没有目标选中或播放结果 | 入口打开成功，原用例后续断言仍未验证或未完成。 |
## 已验证样本与适用限制
2026-10-16 对下列历史任务的复盘已用原始录像交叉核验：
- `50691d8e-2390-4189-b6ac-4cb3c5c32e84`：第 4、6 步确实显示浮层；动作至最终 post 图片入库分别约 25.47、27.50 秒。第 5 步另有点到云台拖柄的定位问题，两类原因分别保留。
- `cd09d017-d5fc-4f12-b366-535d2638199a`：第 4、6、7 步均曾显示声音、高清及全屏浮层；对应入库耗时约 30.03、18.33、31.04 秒。
- 本次页面浮层约 5 秒后隐藏；同设备核验中，约 1 秒内完成唤出及点击“高清”可打开档位菜单。两份原始日志实际走 FlashRunner，相关观测中存在 helper 不可用及 UIAutomator2 回退。
2026-10-16的两个新增失败已精确核对数据库 `initial_goal` 与V7对应F列一致，排除了导入旧稿；原始执行同为FlashRunner，摘要误标Pro不覆盖原始配置：
- `b00d7a56-0a19-4091-a81f-b69923d2385b`（3.3）：第5、7步点位均在真实视频内，动作后最早观测图片已显示“高清”、声音和全屏；第一组早图登记17:11:41.557，最终引用隐藏图登记17:11:46.710，第二组17:12:38.029/17:12:43.661。整步分别约9.65/8.44秒；录屏按真实PTS确认两次浮层各约5秒。早图确已采得但被后续稳定化末图覆盖，是首次入口无法建立的直接原因，不再归为点错面板或产品未弹出。未执行 `click_sequence`，也未开始有效高清10分钟；历史 `failed/blocked` 及质量缺项保持。
- `12f95604-fdcb-426d-a827-af4d4704081c`（3.6）：第5、6、8步后录屏均显示高清/全屏浮层，真实PTS可见区间约96.551–101.106、113.613–118.324、169.850–174.483秒。动作开始至最终图片登记约9.13/24.12/21.73秒；这是登记间隔，不冒充精确采图耗时。只执行普通单击、一次同点双击及收云台，未执行两目标连续序列；Explorer在隐藏末图返回无候选不否定此前出现。259.5秒结束为主动受阻收尾，不是总预算超时；原往返切换、全屏及质量仍未完成。
这两个样本说明“较早图已显示 → 当前核布局 → 重新唤出并连续命中”的首次定位闭环必须在执行端可见，不能仅重复文字要求。helper缺失和UIAutomator2恢复可能放大时延，但不是“全部失败都由helper引起”的结论；本技能的修订与执行层代码修复、服务加载及设备复测分别验收，不改写旧trace或宣称已重新跑通。
上述秒数是本次样本，不是所有 App 的固定等待、超时或连续点击间隔；本技能不固化本次型号、分辨率或坐标。不能把所有“未见”都归为慢观测，也不能因样本成功自动更改历史业务结果。修订历史结论时仅覆盖实际证据支持的断言，保留清晰度往返切换、长时播放及音画质量等尚未完成或需人工判断的范围。
plugins/codex/plugins/artemis-case-prep/skills/artemis-case-prep/references/workbook-contract.md
+430 -9
View File
@@ -1,6 +1,16 @@
# 七列任务表与判定边界 # 七列任务表与判定边界
本参考记录用户所附模板与原始用例的非显然结构，供处理这类工作簿时使用。新输入须重新核对表头和适用性，不要把示例页当作通用列号映射。 本参考记录七列模板、原始用例结构与桌面优化版的项目反馈。模板、原编号、正式提示词信息完整性和证据边界用于通用准备；出现“本轮”、特定编号、环境、路径、数值、条数或运行 ID 的内容仅用于可明确对应的来源项目。新输入须重新核对，不以同编号或附件中的旧确认代替当前资料，也不从历史文字推定当前设备状态。
移动爱家收尾沿用当前安装版的强停及主/前缀子进程核对；优化版“默认返回设备首页”仅作为其他 App 未约定收尾时的回退。当前用户明确的安排优先。业务动作中的“退出App后等待再返回”与整条结束收尾分别处理，不为中间退出擅自加上强停。仅合并 skill 不派发任务、不重写 Excel、不回写历史记录；本文历史样本来自所附文档，合并本身不证明已重新核对原始 trace。
## 按需查找
- 七列结构与支持字段：[模板](#模板)；异构表与行定位：[原始用例](#原始用例)。
- 编写与状态观察：[提示词与决策](#提示词与决策)、[设置页查找](#设置页查找与到底确认)、[截图分辨率与相册](#设备截图分辨率与相册查看)。
- 计时、预算及退出：[长时任务](#长时任务预算与实际计时)、[完成检查与收尾](#用例完成检查与收尾)。
- 既有项目逐条补充：[项目反馈索引](project-feedback.md)、[编码与回看补充](encoding-playback-feedback.md)；相应编号专项只在对应原项目使用。
- 全量项目重出：[68条覆盖核验](#本轮68条重出与覆盖核验)；状态、模型异常与历史证据：[复盘修订](#已有任务表复盘修订)。
## 模板 ## 模板
@@ -20,9 +30,47 @@
不要把新增一列当作导入成功证明。执行前用当时的 `mobile_task_file(action="preview")` 检查文件和逐行错误；本 skill 只准备文档，不启动批次。 不要把新增一列当作导入成功证明。执行前用当时的 `mobile_task_file(action="preview")` 检查文件和逐行错误；本 skill 只准备文档，不启动批次。
## 本轮68条重出与覆盖核验
本节仅在用户明确要求全量重新审阅、应用skill或改写时，用于已确认的移动爱家/长虹SC52034任务集合整合；后续单条复盘默认沿用最新七列任务表，只改对应行的提示词及必要配置，再交付保持原用例集合和格式的Excel副本。保留68行并输出新版xlsx不等于重新改写68条，不默认只交TXT/JSON，也不清空或重写其他条目。本节不作为其他设备或首次原表筛选的固定清单。以指定75条V4删除7条形成的68条集合为范围，读取用户指定或本轮最新已交付版本（本次重出底稿为V6，后续不因本节示例退回旧版），保留原编号、标题、顺序、已确认的雷电模拟器/移动爱家V99.0.0/长虹SC52034环境，以及用户指定的人工判定和收尾安排。沿用已知资料，不因重新应用skill而要求重复提供四项环境信息，也不依据历史completed或新的完成任务并集增回用例。
本轮暂不适用项必须从“任务”页及对应分类行移除：
| 编号 | 用户明确删除的用例 |
| --- | --- |
| 4.12 | 物理遮挡 |
| 9.61 | 设备勿扰（针对具备主动呼叫功能设备） |
| 12.8 | 测试APP绑定时延 |
| 13.12 | 固件MD5校验 |
| 16.2 | 人脸抓拍实际场景算法效果准确率测试 |
| 1.35 | Day7 14:00–17:00智能喇叭持续播放情况 |
| 23.33 | 智能提醒播报频次设置 |
删除限本轮执行集合，不删除仍适用的知识及历史样本（如16.2的云化AI入口误判经验），不推广成所有设备永久不适用。用户后续明确改变范围时按新要求更新。允许在“优化说明”中保留仅含编号、标题及删除依据的变更清单，不放回可导入任务。核对剩余恰为68条，编号及标题逐行对应输入，特别保留1.14、13.13、23.28及4.8，避免按近似文本误删。
逐条按下表路由，核对动作、观察与判据，不把每项规则同时塞入所有用例：
| 本轮优化 | 对应规则与适用边界 |
| --- | --- |
| 直播短时浮层、落点与连续操作 | [短时浮层与连续操作](transient-controls.md)；仅本条确需清晰度、全屏或声音控件时使用，点击回执不证明业务成功。 |
| 4.11四向真实长按与操作视频 | [四向长按与操作视频](#云台四向长按与操作视频411)；逐方向5秒并松手、保留实际操作视频，动作采集与原噪声判定分别验收。 |
| 缩略图顶部二次下拉 | [3.2两条更新链](#缩略图顶部下拉与直播返回更新32)；手动刷新与退出直播后更新分别核验。 |
| 设置长列表、设备信息、日志、固件及夜视 | [设置页查找](#设置页查找与到底确认)、[用户确认路径与采集](#用户确认路径与人工判定采集)；9.69两次调档取完整地址人工判级，13.13当前版本按原三段格式，夜视自动取图例外限本条而不改9.27模式专项。 |
| 人形与声音告警 | [人形设置与状态](#人形侦测与告警判断)、[8.30开启后两分钟](#声音侦测开启与两分钟后检查)、[1.14状态与七天历史](#声音侦测状态与最近七天告警)；三条顺序和修改授权不能互相套用。 |
| 自定义编码参数及互斥 | [本轮各参数路径和范围](#用户确认路径与人工判定采集)、[9.139完整核验](#编码参数互斥与完整核验9139)；码率、分辨率、智能编码与AOV各按本条范围，不能将两开关预设为彼此互斥。 |
| 真实时长与视频码率 | [12.14四组合录像（本轮称9.14）](encoding-playback-feedback.md#1214智能编码下四组合各录5分钟)、[9.101六段30秒](encoding-playback-feedback.md#9101两种码率模式与六段30秒录像)、[长时预算与计时](#长时任务预算与实际计时)、[12.14四组合测量](#编码组合录制与码率判定1214)；实际视频不是手机屏录，单条预算不代替真实业务时长或测量。 |
| 云存/卡存历史空洞 | [12.24最近七天](#最近七天云存卡存空洞检查)、[12.28最近十二小时](#最近十二小时云存卡存空洞检查)；纯白/灰彩口径结合应录制时段，原长稳条件另核。 |
| 第16部分算法入口、人脸启用、车辆及电瓶车 | [第16部分AI入口](#第16部分云化ai算法范围与入口)；16.1按2026-10-21最新口径只查主页面人脸侦测判断本条端侧支持，其余云化用例仍只认AI设置；16.10、16.75负向与16.124四项支持保留各自范围。 |
| 自定义图片上传和人工待核 | [23.28用户调整范围](#自定义图片上传与人工核对)；上传完成不等于原A/B/C及实体效果通过，其他图片用例不套此例外。 |
| 完成检查、异常及收尾 | [完成后再收尾](#用例完成检查与收尾)、[预算与异常](#长时任务预算与实际计时)、[历史复盘](#已有任务表复盘修订)；可做项继续，合法等待与累计模型异常分开，宿主监控不灌入每条业务正文。 |
输出前对68条分别记录采用的规则、保留的原动作/判据、实际修改或“核对后沿用”的依据。已正确的内容可以保留，不为产生差异追加业务动作；删除冲突旧指令、无关规则及重复段落时保留等价要求。用户已改变范围的原步骤标为来源/人工待核，不能同时保留为必做自动门槛。通用宿主归档、模型调用诊断与监控留在交付说明，只有用户指定的截图、录屏、日志或视频是本条验收动作时才写入正文。模板保持七列；新增优化说明或覆盖核验页作为本轮交付元数据，不参与导入。
单条配置沿用已确认值，仅在本条需求确实变化时调整受支持字段并说明；保留4.8操作录屏及6.5、7.4、12.6、12.14既有时长预算，不擅自切换全局模型、开启全局录屏或增大默认时限。保存实际读取的skill文件及哈希、逐条覆盖结果、源/输出身份和真实导入预览结果，便于区分“已按skill准备”与“已在设备上执行通过”。本流程只生成新副本，保留输入及历史结果，不启动批次。
## 原始用例 ## 原始用例
所附“家庭安防多形态终端软件测试用例（移动看家2.0)”有 33 个可见页，不是一个统一表：典型页用 A:G 记录编号、项目、子项、用例、预置条件、步骤、预期；`8告警事件` 表头在第 2 行；`13安全` 的 D:H 才是名称、摘要、前置、步骤、结果；`16 云化AI专项测试-基础包` 用 E:I 记录子项到结果并有重复编号列。页标题还限定白盒、无卡槽、带屏等范围。右侧“新设备/固件变更”之类提测情形不是设备支持声明。`1设备绑定` 的“是否适用”用例行尚为空；设备功能集也未完成真实设备支持信息。因此当前原始文件不满足正式全量转换前置条件。 所附“家庭安防多形态终端软件测试用例（移动看家2.0)”有 33 个可见页，不是一个统一表：典型页用 A:G 记录编号、项目、子项、用例、预置条件、步骤、预期；`8告警事件` 表头在第 2 行；`13安全` 的 D:H 才是名称、摘要、前置、步骤、结果；`16 云化AI专项测试-基础包` 用 E:I 记录子项到结果并有重复编号列。页标题还限定白盒、无卡槽、带屏等范围。右侧“新设备/固件变更”之类提测情形不是设备支持声明。`1设备绑定` 的“是否适用”用例行尚为空；设备功能集也未完成真实设备支持信息。当时该原始文件不满足正式全量转换前置条件；这是原附件的历史状态，新输入是否满足要求须重新核对。
识别时从标题、表头和有实际步骤/期望的行建立用例记录；保留原始 `sheet + row + 编号` 键。合并单元格或续行可承接同一用例，但不要把每个格式行计成独立用例。对无法对应到一条用例的条目报告歧义，不悄悄丢弃。将适用性缺失的行集中列出，先请用户完成原始文档，再生成正式输出。 识别时从标题、表头和有实际步骤/期望的行建立用例记录；保留原始 `sheet + row + 编号` 键。合并单元格或续行可承接同一用例，但不要把每个格式行计成独立用例。对无法对应到一条用例的条目报告歧义，不悄悄丢弃。将适用性缺失的行集中列出，先请用户完成原始文档，再生成正式输出。
@@ -34,24 +82,397 @@
对每条“是”，首字符起按 `【原表显示的用例编号】` + 原“测试用例”文本（仅去首尾多余空白）拼接。保留原文已有的 `【】`，不要再给整段用例标题套一层方括号；编号列和提示词前缀均不附来源工作表/行号，也不要写字面 `+`。例如来源为 `1设备绑定!3` 的用例，编号列填 `1.1`，提示词前缀是 `【1.1】【声波配网】手动长按重置恢复出厂后首次绑定完成配网流程`。这只是格式示例，该行还需人工复位，不能因此标成自动化“是”。若 Excel 数值编号的显示格式与底层数值不同（如 `1.10`），采用原表显示的编号。 对每条“是”，首字符起按 `【原表显示的用例编号】` + 原“测试用例”文本（仅去首尾多余空白）拼接。保留原文已有的 `【】`，不要再给整段用例标题套一层方括号；编号列和提示词前缀均不附来源工作表/行号，也不要写字面 `+`。例如来源为 `1设备绑定!3` 的用例，编号列填 `1.1`，提示词前缀是 `【1.1】【声波配网】手动长按重置恢复出厂后首次绑定完成配网流程`。这只是格式示例，该行还需人工复位，不能因此标成自动化“是”。若 Excel 数值编号的显示格式与底层数值不同（如 `1.10`），采用原表显示的编号。
前缀之后另起完整说明，至少明确：用户确认的模拟器名称或真机环境、测试 App 名称与版本、被测设备名称；沿用测试开始前统一核验过的安装版本，不要求当前用例再次核对；在目标 Android 环境与应用的实际当前状态开始；需要建立的前置条件；依据原文进行的操作；等待**可观察的界面状态**而不是依赖模型思考时间；原文的预期结果和可观察的判定依据。必要的 SN、秘钥、型号可直接写入对应任务，但不能给无关用例灌入这些值。不要把缺失的原文判据补成看似确定的断言。关键操作前后截图、录屏保留、证据路径及“测试佐证”目录归档、阻塞/未验证结论属于 Codex 的执行与报告要求，不写入“Artemis提示词”。 前缀之后另起完整说明，至少明确：用户确认的模拟器名称或真机环境、测试 App 名称与版本、被测设备名称；沿用测试开始前统一核验过的安装版本，不要求当前用例再次核对；在目标 Android 环境与应用的实际当前状态开始；需要建立的前置条件；依据原文进行的操作；等待**可观察的界面状态**而不是依赖模型思考时间；原文的预期结果和可观察的判定依据。必要的 SN、秘钥、型号可直接写入对应任务，但不能给无关用例灌入这些值。不要把缺失的原文判据补成看似确定的断言。互斥类用例按原文明确关系对象及触发条件，不能把组间互斥扩大为同组成员彼此互斥；原文要求关闭的功能、恢复的参数范围和完整提示文案仍须保留。关键操作前后截图、录屏保留、证据路径及“测试佐证”目录归档、阻塞/未验证结论属于 Codex 的执行与报告要求，不写入“Artemis提示词”。
每条用例完成操作与结果观察后，提示 ARTEMIS 返回目标 App 内的设备首页，重新观察并确认首页已显示；即使用例失败或未验证，也尝试完成这一收尾。此处不是 Android 系统桌面，不预设未经核实的导航入口。若用例使设备首页不可达或返回失败，说明当前页面和原因；Codex 在运行下一条用例前确认设备首页已经恢复，未恢复则先处理该状态。 复用执行段时，逐条将新增动作和判据对应回本条原文；查找设置页等操作只在本条确需时加入。系统推荐桌面“选择一套并应用”的用例，不沿用其他用例的 A/B/C 多次更换、自定义桌面、重启或离线验证。原文确实要求这些分支时分别保留；不让额外动作或缺少额外资料改变本条验收。
直播画面中的分辨率切换、全屏、声音开启/关闭等控件可能在点击画面后才显示，也可能藏在随之出现的二级菜单。仅当用例操作确实位于直播页且初次观察未找到目标元素时，提示 ARTEMIS 先截取/查看当前页面，轻点不覆盖明显按钮的直播画面区域一次，再观察新的控件或菜单并尝试定位目标。菜单若短暂显示，应在其可见时完成后续操作；若仍不存在，记录观察和截图，报告未找到，不反复盲点或编造菜单位置。声音开关可核对界面呈现的开/关状态、图标或可观察反馈；若预期要求确认实际声音质量或是否听得到，不能以图标变化冒充听音验证。此提示不是对当前 App 实际界面的预先验证，不能套用于设置页等其他场景。 每条用例先按 [完成检查与收尾条件](#用例完成检查与收尾) 核对操作及结果观察，再按约定收尾。移动爱家在达到退出条件后强制停止 `com.cmri.universalapp` 并由执行方核对主进程及前缀子进程；用户当前明确另有收尾时遵从。其他 App 按当前任务约定，未约定时返回目标 App 内设备首页并确认可见，不将移动爱家包名套给其他 App，也不同时追加冲突收尾。失败或未验证也应收尾，但单项偏差不表示整条可以提前结束。此处不是 Android 系统桌面，不预设未经核实的导航入口；下一条起点与收尾一致。若约定收尾失败，说明当前页面和原因，Codex 在下一条前核对约定状态。
要求强制停止 App 时，先核对当前执行端实际开放的应用管理能力。来源项目的 Flash 执行记录包含原生应用停止动作，执行时须核对当时实际开放的能力；缺少通用 ADB 工具不等于不能停止 App。支持时使用应用管理停止功能，不要求执行者绕到模拟器设置寻找“强制停止”。若执行端不支持或停止失败，收尾交由已授权的宿主 Codex：确认该任务已结束、目标设备空闲且下一条尚未启动后，按已确认的序列号与包名完成停止，并核对用户要求的主进程及子进程状态。看到 Android 桌面不能独立证明进程已停止；不能为补做收尾而中断另一个正在执行的任务。该分工属于后续执行约定，本 skill 不启动或控制批次。
移动爱家支持 ADB 时可执行 `am force-stop com.cmri.universalapp`。若执行端能力不足或未成功，由 Codex 在任务结束、目标设备空闲且下一条尚未启动时，用本条已确认的实际序列号执行 `adb -s <device_serial> shell am force-stop com.cmri.universalapp`；示例中的序列号不是正式任务表占位值。需要宿主收尾时逐条派发，确认本条收尾再开始下一条，避免与运行任务并发操作设备。下一条前检查 Android 进程列表，确认 `com.cmri.universalapp` 及 `com.cmri.universalapp:` 前缀子进程全部停止；停止后又被拉起或无法确认时先处理。下一条重新启动移动爱家、等待真实页面加载并建立前置，版本沿用本轮统一核验结果。失败或未验证也按同一退出条件收尾，不因首个偏差跳过其余可做项。
直播画面中的分辨率切换、全屏、声音开启/关闭等控件可能在轻点画面后短暂显示，也可能通往二级菜单。仅对实际需要这些控件的用例，按 [短时浮层与连续操作](transient-controls.md) 编写：先确认实际视频边界和入口；入口未知时及时定位，入口与当前布局已确认时在可见窗口内连续完成唤出和点击，不把完整观测或整幅直播画面稳定作为两次点击之间的必经步骤。动作描述不证明实际命中；只看到面板展开/折叠须核对落点，布局改变须重新定位。声音开关以实际 UI 状态核验，不能用图标变化代替听音或声音质量判断；本规则不预先证明目标 App 的具体控件存在，也不套用于设置页。
云台控制分别核对方向按钮实际命中、同一直播场景的固定特征变化及原文要求的方向/到位结果。动作已发出、时间戳前进、广告或面板变化不证明摄像头转动；反馈仍在变化或提示需要再次观察时，在换方向、重启或收尾前先补充观察该方向的画面结果。有限补充观察后仍不可辨时，记录对应断言未验证，不反复盲点，也不直接判云台不动。普通方向响应与最终机械限位验收分别判断：原文或用户已确认判据明确要求的独立参照须满足；不能把原文未规定且未核实为必需的角度/规格资料，擅自升级为所有云台动作的硬前置。可独立观察的原分支继续核验，最终限位缺少可信到位证据仍不能判通过，画面不再变化也不等于机械限位到达。
“保存/重启后保持”类用例先按原步骤和预期明确比较对象：当前云台方位、命名预置位或其他已保存设置，不能只凭标题将对象互换或新增创建动作。当前方位保持须先观察调整已生效，并取得可辨的重启前场景/位置参照；已保存配置保持须取得有效起始配置及其标识，原文要求创建/保存时才安排该动作并确认实际保存。原文对象含混时列为待确认；已有任务按用户遇阻处理约定记录受影响断言与缺项。空机位列表不能证明配置持久性，也不能单独否定当前方位可核验；缺乏有效起点时，不用空→空或模糊场景未变证明保持，也不判重启丢失。区分 App 停止/重启与被测设备重启，按原文等待设备恢复及实际直播结果，不用 App 重启代替设备重启。
表单输入须按当前页面确认目标字段，并在输入后核对实际文本和保存条件；动作回执、焦点标记或键盘是否显示都不能单独证明输入成功。字段仍显示占位文字、预期文本未出现或保存条件未满足时，不继续假设已保存；依据当前字段状态有限重新定位或使用实际可用的输入能力，仍未生效则记录未完成范围。输入工具/通道错误与 App 行为分别留待核实，不因多次点按无变化直接判 App 缺陷，也不把工具显示已发出写成文本已进入字段。开关操作也须核对所属设置与实际命中反馈；点到状态栏等无关元素只说明定位未成功，重新观察目标开关后有限纠正，不将该次操作记为开关已切换。该提示不指定未经核实的输入法、坐标或工具回退方式。
带屏设备用例逐项注明观察端：App 的通话状态、配置回读，摄像头实体屏幕，以及对端声音是不同证据来源。“通话中”不证明视频接通；App 的“视频未接通”、编解码调试字段或未显示结束文字属于本端观察，须核对其与原文所指通话通道和屏幕的对应关系，再判断是否违反该项预期。实体屏幕中对方视频、计时、结束文字保持 1 秒和待机恢复，须有对应设备端、对应时点的实际观察；手机界面或模型回合间隔不能代替。缺少带屏适用性或实体观察条件时保留受影响断言，不从 App 控件可见就推断硬件支持，也不将未查到的屏幕效果直接判失败。
桌面主题的 App 预览、应用后“使用中”标记和设备实际待机屏幕分别核验。预览图中的样例日期/时间/星期不代表设备当前值；当前月球主题“使用中”只证明当前选择，不能独立证明出厂默认。原文要求默认状态时须核对可信起点，不能为了补证擅自恢复出厂；更换后的壁纸及日期/时间/星期仍需实体屏幕证据。沿用本轮已确认的保留、恢复或后续用例衔接安排，不自行恢复掉下一条需要的配置，也不以停止 App 代表配置已恢复。
图片上传用例先在目标 App 的实际选择器中确认本轮素材可见、可识别且可选。文件已复制到设备、哈希一致、媒体扫描广播成功或媒体库已有记录，都不能替代这一步。不可见时由已授权执行方按实际权限、媒体登记及刷新情况处理后再核对；仍不可用时保留受影响分支，不改选用户既有照片。可在本轮授权内自主准备的测试素材，不另设为必须由用户提供的条件；本 skill 只编写所需前置与操作，不执行素材导入或设备操作。
分开核验选图、返回 App 的计数/预览、上传反馈、应用和实体显示。选中 N 张、显示 N/N 或添加按钮变灰，只证明所见接受数量与界面状态，不能据此声称第 N+1 张被拒绝、后台逐张成功或设备端生效。原文要求数量上限时，在本条范围及执行授权内尝试超限并观察实际限制；未尝试则保留该项未验证。上传失败分支须由执行方在授权范围内建立真实可控的部分/全部失败并核对原提示；未选择或无法建立方法只影响该分支，不因“未由用户提供失败方案”阻断独立的 App 操作，也不将未触发提示判为产品失败。保留原文对图片格式、大小等测试范围的限定，不擅自扩项。本轮23.28用户已将完成门槛改为上传自定义图片、结果人工核对，按 [本条上传完成口径](#自定义图片上传与人工核对) 采用新增图片身份与留存证据，不强求原应用/实体结果作为自动完成条件。
自定义图片删除或删后再上传时，区分普通列表、删除选择页和确认弹窗；退出选择页的“取消删除”不能代替弹窗“取消”。按本条原文核对勾选对象、弹窗及取消/确认后的图片内容和数量，未出现弹窗就保留该分支未完成。若重新进入删除页时已有勾选但确认无响应，在本轮获准删除的测试素材内，可先实际取消勾选至空圈，再重新勾选并核对确认弹窗、对象和数量变化；只作有限恢复，分别保留首次异常与恢复结果，不据此断言内部根因。删除、上传或列表重排后，按当前图片的可辨标识与内容重新定位，不复用旧位置或元素编号，也不凭动作说明里的图片名称判断实际命中；数量变化不能替代目标身份回读。目标尚未出现在当前可见范围时先查找并重新观察，身份仍不能确认则保留对应操作与应用结果未验证。
缩略图刷新用例先识别目标卡片的实际展示区域及图像内容，再与已观察的同设备直播场景比较。卡片为摄像机产品外观图、直播为天花板等明显不同场景时，内容差异可以直接核验，不能只因卡片没有时间戳就归为“同一静态场景无法区分新旧”。记录具体差异，核对该区域是否为用例要求的缩略图、当前显示模式以及实际刷新/退出后的稳定状态；未完成这些核对时保留异常现象与原因待核实，不立即判产品失败。只有确为同一静态场景且没有独立时间或其他可辨变化时，才采用新旧无法区分的未验证分支；不临时编造刷新时延阈值。本轮3.2手动刷新还须先确认列表到顶、再独立下拉并核实触发，按 [两条更新链的边界](#缩略图顶部下拉与直播返回更新32) 与直播返回更新分别判断。
**移动爱家 App** 点击“设置”后，设置页可能先显示空白、占位或尚未刷新的内容。提示词应要求等待并重新观察，以真实设置内容出现、目标区域可辨认为继续操作的条件；在此之前不点击疑似目标控件，也不把未出现的功能判为缺失。若刷新后仍不能确认页面内容，记录页面状态与证据并报告未能定位，不以固定秒数的等待代替确认。 **移动爱家 App** 点击“设置”后，设置页可能先显示空白、占位或尚未刷新的内容。提示词应要求等待并重新观察，以真实设置内容出现、目标区域可辨认为继续操作的条件；在此之前不点击疑似目标控件，也不把未出现的功能判为缺失。若刷新后仍不能确认页面内容，记录页面状态与证据并报告未能定位，不以固定秒数的等待代替确认。
App 设置页往往较长，目标功能可能在首屏下方。整理设置页用例时，先确认页面已刷新出实际内容；如已加载的首屏未见目标，提示 ARTEMIS 在设置列表中向上滑动较长距离（让下方内容出现），每次滑动后重新查看页面并查找目标；若仍未见，可根据页面变化继续滑动，直到可确认已到列表底部，再记录未找到。不要在未查看新页面时连续盲滑，也不要把用户的“多滑一点”写成未验证的固定像素、次数或坐标。 查找目标时区分灰色分组标题与实际可点击入口。已加载的主列表未出现目标名称，但存在语义相关且可进入的设置项时，可查看该子页并重新观察，查完后返回继续查找；不修改无关设置，也不反复进入已查页面。例如夜视用例在实际页面见到带箭头的“画面与声音”时，可将其作为候选入口查看，但不能据此宣称夜视一定在该菜单内。只滚动到主列表底部而未检查相关子页时，结论只能是“本次已检查的顶层列表未见目标”，须注明未查范围，不能推断 App 或设备不支持该功能。提示词不固化未经实测的二级路径、按钮位置或坐标。
卡回看和云回看的日期/时间轴上，有颜色的区域通常表示有数据，空白区域通常表示无数据。整理有录像片段的回放用例提示词时，先识别当前选中的回看类型及其有颜色区域，再在已经过去的时间中选取该区域并尝试回放，以实际播放/页面结果验证；不要假设卡与云的有数据区相同，也不要仅凭颜色判定回放成功。若用例本身要检验无数据区域，则按原文选择空白的过去时间并核对无数据反馈，不能拿它作为有录像回放失败的证据。选取回放片段前核对当前设备/App 时间和所选时间的时区及先后，不要求拖到未来时间；不能把未来片段不存在判成回放失败。若原用例专门检验时间轴上界，则观察是否无法选取或播放未来时间，记录界面证据，不假定具体控件反馈。颜色含义是用户提供的一般操作线索，具体 App 界面仍须在执行时观察确认。 查找同名或语义相近控件时，先核对其所属功能、检测对象与原文的对应关系；用户已明确区分的功能不再作为替代候选。本轮AI车辆识别、AI电瓶车识别均与AI周界属于不同目标，不再把AI周界中的汽车/非机动车目标、区域入侵或越界侦测列为这些算法候选。普通移动侦测的开关、区域或灵敏度同样不能证明目标算法的身份、支持或已启用，通用“车辆识别”也不自动等同电瓶车识别，按 [车辆及电瓶车算法身份规则](#第16部分云化ai算法范围与入口) 查本条对应开关；原移动侦测区域仅在与目标车辆算法共享配置及映射范围均有确证时按实际范围复用参数证据，电瓶车四项支持的有效共享控件按本条分支分别映射，均不能据此等同算法身份或证明效果。其他尚未明确排除的候选入口打开其他业务页时，先核对其与原功能的对应关系；名称相似或候选控件保存、回读成功不证明原用例设置已完成。尚未核实时只记录候选路径结果及原功能受阻/未验证，不把它当作原功能跳转错误，也不据此推断原功能必须付费。有已核实的共享配置关系时按其实际覆盖范围使用，不覆盖本轮已明确排除的AI车辆/电瓶车识别与AI周界边界。
App 设置页目标未见时，按 [设置页查找与到底确认](#设置页查找与到底确认) 继续检查长列表及相关子页；找到入口或确认滚动边界后再确定下一步，不把尚在推进的页面当作已查到底。
以既有录像为样本的卡回看和云回看，在日期/时间轴上先核对当前存储类型和实际录像轨段，再按本轮已确认的颜色含义选择已有录像；灰色也可能是正常录像，不能把“有颜色”限于鲜艳色。整理有录像片段的回放用例提示词时，先在已经过去的有数据区域选时并尝试回放，以实际播放/页面结果验证；不要假设卡与云的有数据区相同，也不要仅凭颜色判定回放成功。本轮12.24按 [七天空洞检查](#最近七天云存卡存空洞检查) 使用“应录制期间纯白为空洞、灰色/彩色为正常显示”的用户口径，不推广为所有 App 的固定配色。选择回看日期后，依据当前选中状态或日历回读确认目标日已生效，再关联时间轴、事件卡与播放结果；列表出现某日或录像标记不证明已选该日。若用例本身检验无数据区域，按原文选择空白的过去时间并核对反馈，结合录制计划区分正常无数据和应录制却缺段；不能把非录制时段作为有录像回放失败的证据。选取片段前核对可靠当前时间、所选时间的时区及先后，不要求拖到未来；不能把未来片段不存在判成回放失败。若原用例专门检验时间轴上界，则观察是否无法选取或播放未来时间，记录界面证据，不假定具体控件反馈。
6.5及7.4等本次生成型回看不采用先挑已有录像的顺序；按 [直播逐档五分钟与对应云录像](#直播逐档五分钟与对应云录像65) 先实际完成本次直播档位与时长，再定位本次对应过去区间。查看旧片段可以说明已有服务或素材状态，不能补证生成阶段。7.4另按 [卡回放切换点定位与视频](#卡回放本次切换点定位与操作视频74) 将本次过去时刻作为实际选时目标，不能以“无证据区间”为由不拖时间轴就判录像缺失；本次过去目标不要求事先可见彩色轨段才准选择，选择后按真实播放或无数据反馈记录结果。
云回看或卡回看需要把进度条拖至指定时间、但不好拖动或难以定位时，可先点击页面上的“+”放大时间轴，重新观察时间刻度与蓝色光标，再将蓝色光标拖至已记录的目标时间点附近。拖动后读取实际选中时间并观察回放结果；不能仅凭光标接近目标就认定预期满足。若原用例要求精确时间，按原要求定位和判定，不自行定义“附近”的误差范围。这个方法是用户提供的操作线索，执行时确认“+”和蓝色光标确实存在，不预设按钮坐标、放大倍率或点击次数；选时仍遵循上述日期、过去时间及有数据/无数据区域要求。
**仅移动爱家 App**：卡回放目标入口未见时，可先点击“云回看”，重新观察是否出现云回看/卡回放切换，再选择卡回放。其他 App 不沿用这条入口提示；切换未出现时记录当前页面并报告未找到，不编造固定按钮位置。此路径是用户提供的操作线索，真正编写可执行测试代码前仍须用 ARTEMIS 在目标 App 验证。 **仅移动爱家 App**：卡回放目标入口未见时，可先点击“云回看”，重新观察是否出现云回看/卡回放切换，再选择卡回放。其他 App 不沿用这条入口提示；切换未出现时记录当前页面并报告未找到，不编造固定按钮位置。此路径是用户提供的操作线索，真正编写可执行测试代码前仍须用 ARTEMIS 在目标 App 验证。
按设备类型选择分支时，先核对本轮资料的来源、用户确认情况及适用范围。已确认的室内/室外类型等输入直接用于选择原文对应判据，不在同一提示词中又将该分支列为“未提供”；若资料存在但尚未确认，应明确写待确认及原因。设备类型已知与真实夜视场景、独立测距或现场试听尚未核验是不同条件；报告缺项时也作此区分。不能从 App 画面拍摄的是室内场景就反推设备类型，也不改原文的距离、时长或其他阈值。 按硬件能力区分的成对用例分别提取各自原步骤和预期。例如休眠“不支持遮挡机位”分支未要求实体遮挡时，不套用“支持”分支的自动转位、遮挡动作或验收前置；目标设备对应分支尚未核实时记录待确认，不据此新增原文未要求的断言。
整理前置资料时，区分可从目标 App 只读取得的既有名称、数量、配置状态，与必须来自独立来源的预期值和外部条件。原文或已核实界面表明前者可读取时，提示词应先核对对应设备、账号与时点并读取记录；“未人工提供”不等于不存在或无法取得，尚未读取只能记为“未取得/未核实”。读取既有配置与创建、修改配置是不同动作，不能擅自新建机位来补齐保持测试。厂商/设备能力依据、标签原值、第二账号及现场观察等必要独立条件仍须落实，不能用被测输出生成独立预期。无法可靠取得资料时，列明实际未查或受阻范围，并按用户已确认的等待/跳过安排处理，保留未验证断言。保持前置条件原文的时点和范围：仅要求“未开通”等当前状态时，不擅自改成历史“从未开通”；标题涉及“首次”但历史范围未明时列为待确认，不凭标题加强条件。账号已有服务、目标设备已关联及当前录像可播放分别核对，前者不证明后两者。
日志/报文类用例保留原文允许的取证路径。原文允许“日志或报文”时，不将两条路径同时列为必需，也不一律预设由外部人员供证。沿用用户已确认的取证途径与执行分工。已核实 App 可生成日志文件/链接且宿主具备实际读取能力、读取在授权范围内时，提示词写明 App 应完成的采集及可观察反馈，Codex 执行方负责宿主文件取得、按实际格式读取正文和核查；不只凭文件后缀判断格式。用户明确仅采集日志地址/文件交人工核对时，以取得可追溯资料为采集目标，正文判级和一致性结论保留人工待判，不强制自动解析作为采集前提。App 未展示正文只能说明本端未读，不能据此认定没有日志来源。执行记录分别注明来源生成、地址取得、文件取得和正文核查；核对原文要求的日志等级、字段/接口映射和事件时点，历史单次调用或成功码不能证明本次触发、时间实际同步、“每次上线”或“每天凌晨”的完整机制。
临时日志等级等诊断设置先读取并记录原值，需自动判级时依据已确认的档位含义修改，不把“高”推定为 debug，也不把原值推定为出厂默认。用户明确按实际控件调档采集、结果交人工核对时，可记录可读标签或所选位置，不以内部数值或语义映射未知阻断已授权的调档与采集；例如第三刻度不能自行写成等级3。本条约定的采集与观察结束且没有继续采集需求时，若本轮未要求继续保留则恢复原值并观察反馈；停止 App 不能代替设置恢复。未恢复时记录最终值与待处理事项，后续补恢复关联实际执行的运行 ID，不倒填为原用例已恢复。不要固化本次刻度坐标，沿用用户明确要求保留诊断状态的安排。
凡要求信息一致、匹配或同步，编写提示词前核对具体比较字段、独立的预期值或可信来源，以及对应设备、账号、App 版本等范围。比如原用例要求“设备型号和厂商提供的一致”，须先取得厂商提供的目标型号，再将 App 中读到的型号与它比较；不能把 App 显示值同时当成预期和实际。缺少参照信息时列明待补项，等待用户补齐后再编写该条提示词。 凡要求信息一致、匹配或同步，编写提示词前核对具体比较字段、独立的预期值或可信来源，以及对应设备、账号、App 版本等范围。比如原用例要求“设备型号和厂商提供的一致”，须先取得厂商提供的目标型号，再将 App 中读到的型号与它比较；不能把 App 显示值同时当成预期和实际。缺少参照信息时列明待补项，等待用户补齐后再编写该条提示词。
例：原文若要求“进入系统设置，修改一个可见开关并确认状态”，提示词应说明识别目标开关、记录初始状态、执行切换、等界面显示目标状态并记录证据；若原文还要求回退，则依原文回退。示例只说明写法，不证明附件中的某条用例具有这些步骤。 升级类用例按本条原步骤和预期提取条件，不统一套用相邻用例的前置资料。例如只核验升级进度及重启后成功上报时，不追加“升级前全部设置和机位参照”；原文要求升级前后设置保持时，才记录相应基准并在真实升级后逐项比较。真实升级起点、可用且适配的 OTA 包与部署条件仍须落实；已确认可从 App 升级页查询时，先读取实际版本检查结果，不因未人工提供包就省略查询。不能用“当前已是最新”代替本条升级执行。
排除边界：PC 管理端、外接 console、实物遮挡/断电、需要人工听音/看画质、无法自主建立的网络或硬件状态，不标“是”。长时或重复的 Android 操作不是单凭次数就排除，但需有可测的时间/次数、可恢复前置状态和明确结果；缺任一关键条件则标“否”。ARTEMIS Pro 可观察 ADB/日志，不代表能代替外部硬件、PC 或人的感官。 原文要求在本次操作中生成的录制/播放区间、起止时刻和切换边界，在已有可靠独立时钟可用时由执行者按真实动作记录，不因尚未生成就列为必须外部预先提供的资料。原文指定既有录像区间、长稳日期或独立喂流/质量参照时仍须落实；不能用 App 时间轴两端显示互相证明实际喂流时长。保留原文完整时长，不以模型耗时替代计时。显示格式、时区和对应时点未核实时，不只凭状态栏或OSD的表面数值差认定时钟偏移、NTP异常或直播时延。原文“建议”“两种策略均可”“暂无硬性要求”等限定也须保留，不将推荐策略追加为整条用例的硬前置；分别说明可独立核验的操作、尚缺判据的断言与真实外部条件，必要条件未满足时仍按用户约定跳过受阻部分。
原文要求设置重复计划而未限定具体时间值时，先核对计划作用对象，再核对实际界面中既有预设的起止、跨日和循环语义。设备休眠、定时唤醒与屏幕熄灭计划不能仅凭名称相近或互为亮灭状态就等同；只见“关闭屏幕”总开关时，只能说明该页未见计划编辑项，继续按已查范围和相关候选入口核实，不推断全 App 没有计划能力。在已确认允许选择普通可逆测试参数的执行范围内，且能记录原值并确认本轮允许的恢复方式时，可依据可靠当前时间采用有效预设或选择本轮值，不仅因没有人工提供自定义参数就增设外部硬前置。提示词要求实际设置后核对保存反馈、回读及原文要求的生效时点和对应状态；预设可见不证明已保存、已生效或恢复成功。原文规定的固定值、独立期望、业务账号、真实场景和其他必要参照仍须落实，参数语义、时间来源或恢复安排不明时保留待确认；不固化未经核实的保存路径或时段。
例：原文若要求“进入系统设置，修改一个可见开关并确认状态”，提示词应说明识别目标开关、记录初始状态、执行切换、等界面显示目标状态并记录证据；若原文还要求回退，则依原文回退。原文要求在某设置状态下观察效果时，先在该状态仍生效期间完成对应结果观察，再按原文或本轮已确认的恢复安排处理；恢复后的观察不能替代修改状态下的结果。示例只说明写法，不证明附件中的某条用例具有这些步骤。
logo 水印用例（本轮 9.65）先按实际设置核实目标设备支持及开关，读取初始状态；尚未验证的入口只写查找意图，不编造“水印”必在某子页。当前关闭与出厂默认关闭分别核验，缺少可信默认来源时保留默认断言未验证，不擅自恢复出厂。按原步骤开启并回读，保持开启期间核查同设备直播右下角，以及原文要求的云/卡录像、告警、设备列表截图和区域设置画面；记录开启生效时点，关联同一状态时段生成的目标内容，旧录像、旧截图、App 固定标志或仅开关变化不能代替流中水印。各渠道分别记录已验证与缺项；新录像或告警素材尚不可用时有限等待/查询，不伪造外部触发、不无限等待，也不省掉其他可独立核验的渠道。开启状态下的观察结束后，按原步骤关闭并回读、核查原文要求的关闭效果；不能提前关闭后再补开态结论，或用统一“恢复初始值”覆盖原文明确的关闭要求，用户另有明确安排时沿用。开关可操作、各渠道显示、默认状态及关闭效果分别判定，单项完成不等于整条通过。
排除边界：PC 管理端、外接 console、实物遮挡/断电、需要人工听音/看画质、无法自主建立的网络或硬件状态，不标“是”。长时或重复的 Android 操作不是单凭次数就排除，但需有可测的时间/次数、可恢复前置状态和明确结果；信息尚未明确时先列待补项并澄清，只有确认所需条件无法建立或结果无法自动核验时才标“否”。ARTEMIS Pro 可观察 ADB/日志，不代表能代替外部硬件、PC 或人的感官。
当前查看的 `task_import.py` 要求 `任务` 页首行严格为上述七列，并禁止公式、宏和外部链接；`填写说明` 页不作为任务导入。实际部署的 ARTEMIS 版本可能不同，后续执行前核实服务的真实导入契约与逐行预览结果。 当前查看的 `task_import.py` 要求 `任务` 页首行严格为上述七列，并禁止公式、宏和外部链接；`填写说明` 页不作为任务导入。实际部署的 ARTEMIS 版本可能不同，后续执行前核实服务的真实导入契约与逐行预览结果。
## 缩略图顶部下拉与直播返回更新（3.2）
适用于本轮3.2“设备缩略图展示”。用户针对 `0cdd62d4-df03-4aef-9c90-7df979250cef` 明确：需在缩略图展示页回到最上方后再次下拉，不能把列表回滚当刷新；进入直播再返回后的图像更新属于另一条结果。本节修订操作前提及证据边界，不把历史业务失败倒写成整条通过。
1. **正确模式及目标基线**：先按本轮已确认摄像机图标入口进入实际缩略图展示页，核对目标设备、卡片与图像区域，记录原图可辨内容及可读时间。目标在下方时可先定位并记录，然后回到该列表顶部；默认产品外观卡片或其他设备缩略图不能作为目标基线。
2. **回到顶部与下拉刷新分两段**：在真实可滚动区域向下滑，逐次观察页首内容、首卡及其位置变化，确认已到该列表最顶端；只见首卡、固定工具栏或列表向上方移动不等于到顶。一次无变化先核对手势区域、加载及遮挡，有限调整；到顶依据仍不充分时记录未确认，不发明固定次数或历史坐标。已经确认在顶部时直接进入下一段，无需额外滚动。
3. **到顶后独立下拉并核反馈**：确认顶部后，在列表内容区域另做一次下拉，避开状态栏、导航、播放和卡片功能按钮。核对实际可见的下拉提示、刷新指示及结束，或与本次动作对应的内容重新加载等有效响应，再等待列表稳定；不预设本App一定有某种转圈或文字。刷新反馈可能短暂出现，应结合及时观察或已有过程证据，不能强求较晚单张截图仍保留动画；手势成功、列表位移及回弹本身也不能证明刷新已触发。触发无法确认时有限纠正，仍无有效证据记“手动下拉刷新触发未验证”，不把旧图未变直接判刷新功能失败。
4. **手动刷新后独立比较**：完成上段核验后，目标不在首屏时重新滚动找到同一设备，读取稳定图像及可读时间，与刷新前基线比较，分别记录触发/完成依据和图像更新结果。不要在取得该分支结果前进入直播，以免后一个动作改变缩略图而混淆来源。触发或比较受阻时保留具体缺项，继续可独立执行的直播返回分支；不新增固定刷新秒数、缓存时效或后台实现推断。
5. **直播返回更新单独验收**：进入同一目标设备直播，确认实际播放，记录可辨场景及可读时间；退出回原缩略图模式，必要时重新确认模式并定位目标，再比较图像和时间变化。新图相对旧图有明确变化可记录“返回后更新已观察到”，不因前一手动刷新未验证而抹去，也不能由此补证前一下拉已成功。原“退出直播最近画面截图”仍按同设备、对应时点及内容的实际证据核验；较早保存的单帧与返回图构图不同，不单独证明更新失败，也不要求逐像素一致。确为同一静态场景且无可辨时间/变化时保留新旧无法区分，不倒填通过。
6. **结论与收尾**：手动刷新和直播返回更新分别保留已做、受阻及未验证项；两条均已覆盖或剩余项有具体受阻且有限纠正无效后，沿原强停App及执行方进程核对安排收尾。不用进入/返回直播代替顶部手动下拉，不新增云台转动、清缓存、重启设备或其他改变场景的操作来凑更新。
## 自定义图片上传与人工核对
适用于用户针对 `1c060f98-8e88-4d21-88fa-840144f2ef41` 为23.28“更换已应用自定义桌面”明确调整的范围：选择自定义桌面没有相应反馈时，结果人工核对；只要能上传自定义图片就算本次执行完成。这是本条已确认的完成口径，不推广为其他桌面、图片数量上限或上传失败用例一律只上传即可。
1. **完成实际App上传**：进入同一目标设备“设置 → 桌面显示 → 自定义”，按实际“添加图片”等入口从可用选择器选取本轮已获准的可辨图片，完成页面要求的提交/上传。保留素材实际可见、可选及身份核对要求，不因本条放宽效果验收就改选未经本轮允许的用户既有照片；不为凑上传新增数量、格式或删除遍历。上传前后分别核对图片内容与列表状态；只在相册勾选、点击提交或计数变化，均不能单独证明新增目标图已进入App列表。
2. **以新增图片留存确认操作完成**：提交返回后，本次目标图片在自定义列表中实际出现，内容/标识可辨，有限观察或再次返回仍在，且无明确上传失败反馈，可作为本条App侧上传执行完成的依据；结合实际数量变化说明，不仅凭N/N或按钮颜色。无需强求特定“上传成功”吐司；后台逐文件传输和实体显示不由此推断。目标图未出现、仍无法确认身份或明确报上传失败时，按当前反馈有限纠正，仍未完成则如实保留上传受阻，不能用“人工核对”掩盖尚未完成的上传。
3. **选择无反馈交人工，达到新门槛后收尾**：选中自定义页或图片后，若有限观察仍无明确应用、选中或设备端反馈，记录当前页面、实际操作及未见反馈，结果交人工核对；这不是上传失败或设备不支持的充分证据。不反复点击同一图片、虚构应用按钮或为补旧验收切换其他系统主题。原A/B/C切换、B/C实体屏幕显示及过程无重启/离线的要求保留为来源判据和人工待核结果，不再阻断本次上传完成，也不要求先建立实体A才能执行上传。按新口径分别交付“上传执行完成/受阻”和“桌面效果人工待核”，不能写成整条原功能自动通过。
4. **保留待核对象及原App收尾**：记录上传图片身份、实际列表留存和最终页面/配置，按本轮已明确的保留、恢复或后续衔接安排处理；未有清理安排时，不为了结束而删除待核新图或覆盖待核状态。若旧运行已切换系统主题，记录其真实末态，不冒称已恢复或要求重放旧操作。按原要求强制停止App并由执行方核对约定进程状态，不能把收尾代替未完成上传；此skill仍仅修订操作说明，不重跑设备或回写历史结果。
## 直播逐档五分钟与对应云录像（6.5）
适用于6.5“回放不同清晰度的云回放”。用户针对 `f0044b0a-4439-434a-9d88-a092ad232a90` 再次确认：在直播页面切换分辨率/清晰度，每个实际可用档位播放5分钟，再查看对应云存。保留原“音视频是否在不同清晰度模式下切换；不存在断点”判据及本条原收尾、配置；本节只修本条依赖与完成条件，不加12.14的H265/H264四组合、码率测量或App内录像动作。
1. **先区分可辨内容与实际播放**：本条清晰度入口在直播页，按实际菜单读取档位名称，不以设备设置“自定义编码参数”代替，也不由高清/超清标签猜具体像素值。真实出图、播放器反馈、多时点画面或可用连续证据用于确认播放；画面主体失焦、灰白或缺少清晰固定参照不能单独否定播放，更不能直接跳过菜单、切档和计时。画质与声音缺证据分别保留待核。持续加载、离线、错误、断流需有限恢复且不计为有效播放；不为可辨场景反复调云台或扩展无关设置。
2. **误点反馈必须纠正**：先按当前截图分别核真实视频矩形、相机/录像工具栏及云台面板拖柄，整屏中心或面板中心不等于视频中心，使用归一化坐标时按本次截图尺寸核落点在视频内，不套历史坐标或偏移；切页返回后重新定位。随后唤出落点在图像内无按钮处并远离底部工具栏、拖柄和云台。出现截图预览、录像状态或其他工具反馈，说明未完成正确唤出；重新观察、定位并有限纠正，不把误点后未见菜单当作设备不支持。短时浮层沿 [早图与连续操作](transient-controls.md) 识别入口、核当前布局；已隐藏且布局未变时用实际受支持的连续点击完成重新唤出与入口点击，不使用固定旧坐标、旧元素索引或同点双击。
3. **阶段A/B为逐档选择和真实300秒**：打开直播清晰度菜单并记录本设备实际全部可用档位。每档先实际选择并核对选中与恢复播放，再保持该档连续播放300秒；完成后才切下一档。初始档已选中可核验后从本次时点计时，其余档仍须实际切换；不能只打开菜单、只看标签、只测一档或把多档合计5分钟当作完成。实际只有一档时记录“不同清晰度”覆盖不足，不臆造其他档位。
4. **本次起止表由执行动作产生**：逐档记录设备、档位、选中反馈、可靠开始时刻t0、截止t0+300秒、实际结束时刻、切换边界及中断。使用实际支持的时钟和分段等待，按剩余真实时间安排，段间核播放状态与推进；不从任务开始、回看或模型回合数计时，也不机械追加已过的完整300秒。模型处理耗时只有播放条件持续成立时才计入，不能按平均耗时估算。真实中断如实记录，允许恢复后重新建立完整区间或保留该档未完成，不拼接冒充连续5分钟；无人工预先提供本次时刻表的要求。
5. **独立云存探查与阶段C分开**：云存状态未核实时先实际进入同设备云回看，确认当前存储类型、加载、已选日期、套餐/访问反馈、录像列表或时间轴；有线索时选已过去的时段实际点播或拖轴并回读日期时间、播放推进。灰色/彩色均可作查找线索，不以单个空时段、推广卡、其他服务未开通或只见入口文字断言无云存；默认日期空白时按实际可选的相关近期日期/时段有界查找，区分明确未开通/到期或权限限制、已查范围无录像、加载故障/未核实，不购买或改录制模式。此探查可在A/B前执行，清晰度局部受阻时也应独立尝试，不能仅写“云服务未核实”就结束。旧片段可播放只说明该历史范围可访问，不证明当前新录制或本次档位视频已生成；探查结束回同设备直播重新定位，继续可做的A/B，单纯无旧片段不构成禁止生成，真实服务/设备故障影响相应依赖阶段。阶段C仍只核本次已生成片段，不能以预探查替代。进入对应云录像核查前，逐档核对实际选中、连续300秒、起止与切换边界。可补做漏项先留在/返回直播补完；确有具体故障且有限恢复无效时记录受阻阶段与缺项，不用旧录像补成已完成。为核云服务而临时查看回看页，不能代替A/B，具备条件后仍须回直播完成。全部实际档位完成后，才按同设备、实际时区、已生效日期、本次过去区间定位云录像；灰色/彩色是本轮有数据线索，实际播放及时间回读才确认对应，不把视频灰白等同于时间轴纯白空洞。
6. **对应录像与原判据分别核验**：逐档及切换边界实际回放，观察音视频切换、播放推进与连续性，保留原无断点要求；回放页当前清晰度标签、时间轴颜色或任意旧事件均不证明本次云录像历史编码发生切换。新录像未就绪的分支仅在A/B已完成并记录本次区间后适用，按实际反馈与剩余预算有界等待、刷新或重进回查；记录可查范围与缺项，不无限等、不选未来、不换任意旧日期。云服务需关联目标设备，不从其他服务卡“未开通”推云存状态，不擅自购买或更改录制模式。
7. **收尾核对具体覆盖**：先核独立云存探查是否实际访问/试播或取得明确页面限制；清晰度失败且入口仍可用时先补探查，未访问不能当已确认无云存，已查无片段结论限定范围。再分别记录“生成未做/部分完成”“生成已做但对应云录像未就绪”“对应云录像已查及原判据覆盖”。画质、声音或历史编码证据不足只影响相关断言，继续仍可独立执行的动作和观察。未做且仍能执行的逐档操作/计时不能仅标未验证后停止App；满足全部必做项、剩余确有具体受阻且有限恢复无效、用户取消或实际预算终止后，沿原强停App安排收尾。生命周期completed不等于本条业务完成或通过；本次文案修订不改历史结果、不自动重跑。沿用已确认的 `{"profile":"flash","timeout_seconds":3600}`，不改全局配置。
## 卡回放本次切换点定位与操作视频（7.4）
用户针对 `5250cbe5-e63f-488d-b315-204aad62fc0f` 明确：在卡回看拖动进度条到切换分辨率的时点查看，本条不需要ARTEMIS判断音频，只保留操作视频。原编号、直播每档5分钟、TF卡前置及卡回放顺序保留；原音频判据转人工待核，不能继续作为自动完成的硬门槛，也不推广到其他用例。
1. **记录本次直播样本**：在直播页按实际菜单核清晰度，逐个可用档位选择、确认选中与恢复播放，每档连续300秒，记录同设备、档位、开始/结束和每次切换边界。初始档核验或切至高清等档位并确认恢复播放后，实际建立本档t0；尚未到t0+300秒且直播持续时，下一动作应为受支持的等待配合观察，不能因尚未完成等待/回看直接stop。当前执行端wait_for_delay(time_in_ms)以毫秒计，300秒为300000毫秒；按工具单次上限及真实剩余时间分段，不每轮重等完整300000毫秒，不拿总会话时长代替本档计时。未调用等待不是等待能力受阻，实际错误则保留回执并有限处理。计时按 [真实计时](#长时任务预算与实际计时)，浮层按 [早图与连续操作](transient-controls.md)。高清/标清等实际可用档不能因另一档受限或音频待人工而省略；仅30秒体验、付费限制或无法维持300秒的档单列受限，不购买、不反复试用拼足5分钟，继续其余可用档及已完成区间回看。
2. **核类型与日期后实际拖动**：确认同设备、实际“卡回看/卡回放”、对应日期已选中，不能把“今”已选却未列入旧摘要写成日期未知。进入时的默认旧帧/指针只代表当前选时，未定位本次时段前不能断言卡录像不存在。右侧云服务推广卡不代表整页为云回看或卡时间轴不可用；灰色也可能是本轮正常录像轨段。确有无卡、权限/加载错误时记录真实反馈，可按已授权范围只读核存储状态；不把缺少实体插卡证明加成一切UI操作前置，不格式化、不改录像计划。
3. **本次时点是必做选时目标**：读取刻度、指针与可拖动区域，先在实际时间轴内小幅试拖，回读前后选中时刻确定方向；再小步拖至本次各档区间和每个实际切换点之前，松手待加载/恢复播放，核日期、时区及播放时间确实对应，再播放跨过边界并记录切换后的显示。已有本次过去起止表就可用于定位，不要求先有彩色条/预览/已播放证据才准拖；时间轴颜色不是拖动许可，也不是播放结果。目标不在当前视段时继续在时间轴内推进，必要时用实际存在的缩放/日期入口；不在事件列表或推广卡上滑动冒充选时，不固化方向、坐标或精度阈值，不选未来。
4. **拖动无效与无录像分别验收**：手势回执成功不等于选时成功。时刻未变时先核手势是否在时间轴、是否被弹层拦截以及页面是否加载完成，再有限调整落点/幅度并回读。确实无法拖动则记录动作、时刻与受阻范围；拖至目标后明确无数据/不可播放才记录相应区间结果，可按实际反馈有界回查近期索引。不能因未拖就说本次未生成，也不因有灰色轨段就说录像必然正常；不得用其他时间或云录像替代。
5. **原策略和音频边界**：保留厂商可自定义卡码率、随直播切换码率或固定码率均可、暂无硬性要求。只记录对应片段实际显示、时间推进及切换前后操作，不从播放标签、模糊观感或未变分辨率断言卡编码策略失败。原音频效果交人工；不要求自动听音、音频采样、扬声器权限或有效音轨，不因缺音频证据停止其他可做动作。
6. **单条录屏与完成口径**：沿用Flash及3600秒，本条配置仅增加 `record_video:true`、`analyze_video:false`，不改全局。视频覆盖直播清晰度选择、各档播放、卡回看类型/日期、实际拖轴、时刻回读及对应播放过程；App内录像和截图不能替代模拟器操作录屏。宿主在派发及执行期间核实际录制启动与持续状态，任务结束后核最终文件及可播放性，给出真实路径并关联各阶段时间；缺操作片段或文件保留采集缺项，不让Flash调用不存在的录屏控制工具，也不要求Flash等最终成片才停App。视频无音轨不构成本条音频自动失败，不承诺该视频可供听音。本次采集完成须待宿主取得最终视频确认，与原人工业务结论分开；只选中高清等档位且无真实终止条件时，继续本档计时、其他可用档及卡回看，不能先强停再把未做项全部列未验证。音频待人工、其他档试用限制、成片尚未结束不阻断仍可执行的阶段；仍可执行的拖动/回读先补完，再按原强停收尾，真故障或预算退出如实记未完成。保留旧结果，不自动重跑。
## 休眠直播检查与唤醒恢复（9.32）
本节针对任务`e898b8d4-9242-4086-b024-e5e7f78c9b22`及用户补充的9.32范围：开启休眠后必须查看直播，并执行唤醒、核验直播恢复。保留本条“不支持云台遮挡机位”的原文和适用性待核项，不给9.32追加9.33的实体转位遮挡，也不把本次改动自动写到9.33或定时休眠用例。
1. **先建立并核对休眠态**：确认同一目标设备，记录休眠初始状态；实际关闭时开启并核必要保存/回读，已开启则核验后沿用，不为凑开关动作先关再开。开关回执、颜色及“设置成功”分别如实记录，不单独证明视频流已休眠。可信硬件分支资料不足时保留该项未核，不因此跳过用户已明确要求且可独立完成的App操作。
2. **在唤醒前实际进入直播**：从休眠设置返回同设备直播并确认已进入实际视频区域；一次BACK可能只到设备设置外层，须按当前页面继续导航。保持休眠生效，先读取App休眠提示及实际黑屏、马赛克或其他推流现象，不先点击“唤醒”。进入时出现唤醒提示则先观察当前休眠反馈，再进入唤醒阶段。若进入直播会自动唤醒，记录实际转变及休眠态观察缺项，不声称仍在休眠；普通离线、持续加载或原有占位图不能自动判为休眠推流符合预期。原文预期样式不符、画面仍正常等分别记偏差，仍继续可执行的恢复。
3. **真正唤醒并回读**：按当前界面实际提供的直播“唤醒”等入口，或返回同设备设置关闭“设备休眠”，核必要确认/保存和反馈，再回读休眠关闭状态；不存在专属唤醒按钮时使用已定位的休眠开关，不臆造路径或连续盲点。先确认当前状态，已经关闭时保持，不重复翻转。原智能喇叭、智话等功能条件缺失只影响各自断言，不能阻断这次独立唤醒；不新增重启、断电、实体遮挡或云台动作。
4. **唤醒后再查看直播恢复**：进入或留在同设备直播，等待实际加载，检查休眠提示是否解除、当前视频是否出图及有无可观察的播放推进；结合画面时钟、场景变化或实际播放状态，不只凭旧单帧、播放图标、开关关闭或“设置成功”判恢复正常。若直播恢复但开关无法回读，分别记录画面已恢复及设置状态未验证；持续黑屏/加载/报错则如实保留恢复异常或未验证，不把它当正常休眠继续结束。检查只覆盖本条恢复，不追加固定播放时长或音画质量指标。
5. **检查覆盖及末态后收尾**：明确核对“休眠开启/回读—休眠期间直播观察—唤醒/关闭及反馈回读—唤醒后直播恢复”四阶段。尚可执行的漏项先补完；原智能喇叭/智话、硬件分支及实体/声音观察缺条件时各自保留未验证，不冒充整条通过。有限纠正当前页、加载、弹窗或实际入口后仍无法继续时，记录具体受阻阶段、最后可见休眠/直播状态及是否仍待人工唤醒，再按原强停App及进程核对安排收尾。本次以用户要求的唤醒末态为准，不为恢复初始休眠值再次开启休眠；强停App既不代表唤醒，也不代表已完成两次直播检查。保持本条Flash及原任务配置，不为普通状态检查增加录屏、长时等待或全局改动。
## 长时任务预算与实际计时
1. **派发前核对有效总预算**：真实持续播放/等待时长只是整条执行的一部分，还要计入启动 App、定位设备、加载、测量、有限恢复及收尾，按实际估算预留余量。核对当前单条覆盖值及继承的批次/全局时限；提示词写“等待30分钟”不修改调度预算，普通业务等待计入总时限。30分钟播放用例不能继承恰好1800秒总预算；在受支持的本条 `任务配置(JSON)` 中明确覆盖，例如 `{"timeout_seconds":3600}`，有其他已确认字段时合并保留。本示例只用于本类时长及余量安排，不统一提高所有用例或全局默认，也不以延长模型请求超时代替业务预算。超出当前平台单条支持时限的长周期按已有编排条件处理，不能填写不受支持的数值。
2. **明确业务计时起点与剩余时间**：先确认目标设备直播已实际出图并在播放；加载占位、灰白模糊单帧或“直播”标签不能单独证明正常持续播放，也不能仅凭内容模糊就否定实际播放或阻断仍可操作的清晰度选择。按多时点画面/播放器反馈与实际可用连续证据核对播放状态，画质可辨性与播放状态分别判断；明确持续加载、离线、播放错误或断流不计有效播放。以本次确认正常播放的可靠时点为 `t0`，记录实际截止时间 `t0+原时长`；每轮依据可靠时钟计算已过及剩余时间，期间导航、观察和模型处理只有在播放条件持续成立时才计入，不按回合数或平均模型耗时推定。不能从任务启动、排队或未知历史播放时点起算，也不在已过部分有效播放时间后重新追加完整30分钟。进入等待前再次核对剩余总预算是否足够完成剩余业务、测量和收尾，预算不足不发送注定跨过任务截止时间的长等待；记录调度条件缺口，后续按已有授权配置与执行安排处理，不缩短原时长。
3. **分段等待并核对播放连续性**：使用实际支持的等待、时钟和观察能力，按剩余时间安排较短等待段，段间观察同设备、播放推进、有无断流/错误/离开直播；宿主按工具建议进行有界状态查询，避免一条全程等待使中途没有检查机会。分段解决可观察性，不能解决总预算不足；段间实际耗时计入可靠计时，不能机械叠加成30分钟外的额外等待。仅结束时仍停在直播页或时间戳增长不充分证明全程无中断，结论按实际观察及可用连续证据的覆盖报告。实际中断时保留中断及其时点，需满足连续时长时应在允许恢复后重新建立有效区间或保留该断言未完成，不能把中断前后拼接冒充连续30分钟。
4. **12.6 的等待与时延测量分开验收**：原要求连续实况播放30分钟后记录图像时延 `t`，判据 `t≤2s` 保留。执行前核对可用的独立采集至呈现时间参照或可靠同步测量方法，自主可建立的普通计时由执行方准备，不强制唯一工具，也不编造外部时钟或现场素材。方法未落实时记录时延测量缺项，等待本身不能补足测量能力；可独立执行的播放观察按本轮安排保留。OSD 与系统时间在时区、格式、时钟同步及对应采集时点未核实时，不能把表面差值当作时延或 NTP 缺陷；录屏时长、等待回执或总会话时长也不证明 `t≤2s`。
5. **区分合法等待与异常停滞**：核对最后有效动作、等待参数及其开始/结束状态，再判断没有新 UI 步骤的原因。明确正在执行、仍在原业务时窗且预算充分的等待，不套用“模型无进展”退出逻辑；连续模型请求超时、未产生等待动作或等待超出真实预算则按异常分支诊断。超时终止后单独核对 App 收尾，不能把 runner 被回收、设备锁释放或录屏结束当成已强制停止 App。本 skill 只编写预算、阶段及交接要求，不实际改变全局时限、启动长时任务或补做设备动作。
## 用例完成检查与收尾
编写提示词时，把本条原操作、各状态下的结果观察及恢复要求对应成必要阶段，明确进入收尾前还须完成哪些读取和比较；使用执行端实际可用的计划/检查项能力，不发明工具。普通短任务可直接写清阶段，不强制更换 Flash/Pro 或增添专门文件。
1. **逐项核对后再结束**：在返回首页、强制停止 App 或上报整条结束前，对照本条必需项区分已执行、尚未执行及实际受阻。操作已完成但对应效果未观察，或要求多个字段却只读了一项，均属未完成；无实际阻碍时继续补做。原文“任意一项”仍只需按其量词执行，不能把退出检查变成额外遍历。
2. **偏差与后续覆盖分开**：弹窗文案不符、某项失败、可信默认依据缺失等，只影响对应判定；按原预期保留偏差，继续独立可做的开关、字段回读及其他分支。不能以“已发现问题”“未验证”或“准备收尾”为由放弃仍可执行的项目。App内业务录像的开始、规定真实时长、停止与保存分别检查；未尝试录像/等待不构成它们受阻，缺SDK/RTSP、提取分析或长期条件不直接阻断可做App录像，详见 [录像共同规则](encoding-playback-feedback.md#写入任务表的共同规则)。某动作会破坏尚需观察的状态时，先观察该状态再继续或恢复；禁止用手动恢复、重复已有动作掩盖缺项。
3. **明确退出条件并保留原收尾**：全部必要动作与可做观察已执行后收尾；剩余项确实受阻时先按该分支有限纠正，保留具体缺失条件、尝试动作及反馈，并完成其余独立项目后收尾。用户取消、实际预算终止或不可继续的设备/工具故障时按真实情况退出，不无限重试、不越权补条件。失败和受阻也执行原约定的 App 收尾，但停止 App、释放设备或执行状态 `completed` 都不能代替业务完成。宿主终态检查发现漏项时如实标明覆盖缺口，不倒填通过；未获重跑安排时不自动新建任务补测。
## 云台四向长按与操作视频（4.11）
本轮4.11“转动噪声要求”按用户新增要求，先完成上、下、左、右各真实持续按住5秒并保留操作视频；原“设备转动过程中无明显噪声”继续保留，不以无声音证据为由省略仍可执行的四向动作。此处只更新本条采集和完成门槛，不给4.3机械限位或4.8真实OTA增加或删除断言。
1. **按当前页面定位四个方向。** 确认目标设备直播，打开实际云台面板，核对四个箭头及命中位置；不是点击方向盘内圈、预置位图标或视频画面。记录可辨的固定场景参照；无可辨画面时保留转动效果未验证，但按钮可可靠定位且不存在不可继续的故障时仍执行四方向按压。原步骤的“旋转视频源”若含义或入口尚未核实，单列该步骤缺项，不凭空切换镜像、倒装、横竖屏，也不以此跳过明确可做的四向动作。
2. **逐方向真实按住5000ms再松开。** 按上→下→左→右顺序分别执行实际持续按压，再观察松手后的状态及固定特征变化，随后定位下一方向。使用执行端真实提供的时长参数；当前安卓工具`long_press`的`duration`以毫秒计，5秒写5000，执行时仍核其实际工具约束及回执，不编造参数。一次短点后`wait(5)`、`click_sequence`的`delay_ms=5000`、四个快速tap或仅一个方向的1800ms长按，都不满足四向各5秒；模型推理和截图耗时不抵扣按住时长。若时长能力不可用或动作报错，保留对应方向受阻，不擅自截短或改成连续短点。
3. **四项覆盖明确记账。** 对上、下、左、右分别关联实际动作、请求按压时长、回执、松手及画面反馈，缺方向、短时长或无回执分别记缺项。参数和成功回执可证明已请求/执行对应按压，不单独证明机械转动或精确物理触点时长；画面变化仍需可辨参照。单方向效果不明时有限观察与定位纠正，不能反复用上方向代替其余三项。缺少噪声证据只影响声音判定，不阻断其余可做操作。
4. **以单条配置保存操作视频。** 本条`任务配置(JSON)`设置`record_video:true`；按当前人工交付范围可设`analyze_video:false`，保留其余配置，不改变全局默认。操作视频覆盖按压前、四次持续按压、松手后观察，保存并关联本任务真实文件、可播放性和各方向时间。宿主执行方核对实际录制启动及结束产物，不让Flash调用不存在的录屏查询工具；App内录像仅录摄像头画面，不能替代模拟器按钮操作视频，截图也不能替代。视频无音轨或无法确认声音来源时，不能证明设备机械噪声；不得默认新增录音权限或改全局音频配置。
5. **完成动作采集再收尾，业务结论另核。** 四方向均达到本条按压要求且操作视频已保存，才可说本轮动作/视频采集完成；宿主尚未取得视频时标待交付，实际故障退出时列出已做与缺项，不宣称完整完成。保留原强停App收尾，但不能因没有录音或一方向画面不明就提前停止其余可执行动作。原噪声结论只有可靠转动期间声音证据才可判定，否则交人工核对；自动采集完成不等于无明显噪声通过。
历史样本`de6e9a60-3659-4431-9fa2-790a96402a56`实际初始目标为4.11：第3步`click_sequence`只发四个tap，`delay_ms=800`为点间等待；第4步仅向上`long_press duration=1800`；第5步停止App，第6步主动上报`completed`。原图及顺序解码录像核对四个落点较对应箭头整体偏上约144–175像素，落在拖柄附近、圆盘中心或盘外空白；第4步重复错误上向位置，属于视觉定位错误，不是归一化坐标换算错误，也没有证据表明动作时面板上移。最终业务结果是`inconclusive`，不是通过；PASS目录名和success日志不覆盖该业务结论。原提示词仅写“点击云台上下左右”和取得噪声，未将四向5000ms及视频交付作为本条显式门槛；其他云台用例已有5秒规则不能自动补入本条执行正文。录制停止虽报错，本地MP4仍存在且完整解码通过，约148.74秒、只有视频流无音轨，不能证明机械声音。后续修订不倒填该历史任务四向5秒已完成，也不自动重跑；样本偏移和坐标不作为新布局的固定修正量。
## 设置页查找与到底确认
设置页用例的提示词须包含本条所需的持续查找及停止条件；不能只写“合理查找后未见则结束”，让执行者在仍有下方条目时提前放弃。以下按页面实际反馈执行，不以增加任务时限或盲滑次数代替覆盖：
1. **先加载并沿已确认路径查找**：确认目标设备及设置内容已加载。已有用户确认路径时优先定位实际入口；本轮码率、分辨率、智能编码及 AOV 的设备编码配置到设置页下方“自定义编码参数”查找，9.139第二轮用户称“自定义码率参数”，按当前入口标签与实际码率/帧率/I帧间隔及相关开关核实目标。进入可操作页后再找目标控件；能力集或原始Config只读展示不等于编码参数设置页，不能只在主列表匹配功能名称或反复进入“画面与声音”“AI设置”。12.14 采样时的高清/超清选择仍在直播页操作，按 [编码组合录制](#编码组合录制与码率判定1214) 区分两处作用。第16部分中16.1按 [最新端侧例外](#第16部分云化ai算法范围与入口) 先只查主页面“人脸侦测”，其余云化AI用例仍到“设置 → AI设置”核对本条算法，不能以近名端侧功能或“云存储专属”标记替代云化目标。其他功能仍按自己的已确认路径或实际相关入口，不一律塞入编码参数页。目标出现即进入，不要求每条先遍历到底。
2. **有新内容就继续向下查**：目标尚未出现时，在实际可滚动列表区域向上滑动，让更下方内容出现；可采用适合当前页面的较长手势，但保留部分已见条目作为衔接，避免越过未查区域。每次等待页面稳定后，比较顶部/底部条目及其位置，检查新出现的行和入口。只要新条目出现或列表位置仍在推进，就继续查找，不能因已滑数次、看到“功能设置”“增值服务”“其他”“固件升级”“设备检测”或“网络切换”而宣称到底。本轮这些区域之后仍可能有开发者选项及“自定义编码参数”，以当前页面为准，不固化分组顺序或坐标。
3. **核实末尾，区分手势无效与到底**：明确指向列表底端的边界反馈可以作为末尾证据，普通手势执行成功或滑动动画结束不证明到底；没有此类反馈时，先确认手势落在正确列表、无弹层拦截、内容已加载稳定，再有效续滑并核对末尾条目及相对位置是否不再推进。单次无变化不证明到底，先有限调整手势落点或幅度并重新观察；仍无法辨认是手势无效、页面未加载还是已到末尾时，报告“滚动受阻/末尾未确认”，记录最后可见范围及未查部分，不写已遍历完整。不得连续无观察盲滑，也不发明固定像素、滑动次数或无期限重试。
4. **末尾与功能结论分开**：目标仍未定位且已确认主列表末尾时，通常仍须核对与目标相关且尚未查看的实际可点击子页，查完回到已记录位置继续，不循环同一候选页、不修改无关设置。**16.1例外只以完整主列表中是否有“人脸侦测”为本条支持判断，不进入AI设置、AI周界等子页另找算法**，按下节的最新用户口径记录结果；主列表未加载、未查完或滚动受阻不能按无入口处理。其他用例区分“已定位”“已确认主列表到底但相关子页未查”“已查范围未见”“滚动/加载受阻”；注明已查入口、最后可见条目、末尾依据和未查范围。通常未定位不等于设备不支持，按本条能力分支保留待核对结论。任务预算或实际页面故障使查找中断时如实报告部分覆盖，不能为满足到底要求无限运行。
## 人形侦测与告警判断
按本轮用户针对移动爱家目标设备的补充，人形侦测告警及其事件视频用例先核对设置，再核对启用状态，最后按本条范围判断告警；不能从告警筛选分类、空历史或直播画面反推设备能力。后续提示词按以下分支编写，不预设未经核实的二级菜单：
1. **先查设备设置**：确认是同一目标设备的“设置”页，等待实际内容加载，按前述设置页查找边界检查列表下方及语义相关子页。找到“人形侦测”或已核实对应同一功能的设置才进入启用检查；未见时记录已查与未查范围，说明“设备设置中未见人形侦测，可能不支持，需人工核对”。查找不完整或页面未加载时另记定位受阻，不能直接判设备不支持、产品失败或用例通过。
2. **再查是否开启**：读取并记录该功能的实际开关/启用状态，入口存在不等于已启用。关闭时记录当前未开启；若本条要求验证本次触发，说明该触发前置未满足。仅在本条原步骤或本轮授权要求开启时才操作，并核对保存反馈及回读，不能把查看改成默认开启。状态读不出或开启未确认时，保留启用状态及本次触发结论未验证；当前关闭也不能证明历史从未产生告警。
3. **最后判断告警**：对本次触发的判断，须先确认人形侦测已开启，再核对本条要求的真实人形触发条件、对应设备与时点及有效观察时窗，查找对应人形事件，记录在有效时窗内告警产生或未产生。前置满足且观察完整时按原预期判定；缺少真实触发、有效时窗或可靠的观察证据时写明缺项和告警未验证，不能仅以无记录判漏报。不编造固定等待阈值或让 ARTEMIS 等待未落实的外部动作。区域入侵、普通移动侦测与人形侦测仅在功能对应关系已核实时按覆盖范围使用。事件生成、消息推送与视频可播放分别按原预期核验，不互相代替。
4. **保留事件视频用例的范围**：8.8“人形告警视频质量”在设置及启用状态核查后，仍可查找同设备其他日期的既有真实人形事件，核实事件身份后播放对应视频，再检查本条原音画要求；本条原文允许既有素材，不因新增设置核查一律强制新触发。当前已开启不证明历史事件发生时的配置或本次已触发，未找到可确认的人形视频时保留视频及音画质量未验证。直播噪点或其他类别的视频不能替代目标视频证据；按本轮已确认安排，需人工评价的音画结论仍交人工，不以播放或采集完成代替通过。
## 声音侦测开启与两分钟后检查
本轮用户针对 8.30“声音告警视频质量”补充了操作顺序：到目标设备“设置”开启声音侦测，等2分钟后检查对应告警。这是本条已确认的开启安排；编写后续提示词时直接采用，不重复询问是否允许开启，也不将历史列表查找替代这些动作。本 skill 仍只修订提示词，不启动或重跑设备任务。
1. **先开启并确认**：进入同一目标设备的“设置”，等待实际内容加载，按设置页查找边界定位声音侦测。读取初始状态；关闭时开启，存在保存操作时完成保存，再回读确认已开启；原已开启则保持，不先关再开。未定位、无法读取或开启未生效时记录具体阻碍及已查/未查范围，未见入口的支持情况留待人工核对，不能把点击回执或告警分类当作已开启，也不修改无关设置。
2. **从确认时点等2分钟**：以本次确认声音侦测已开启且必要保存完成的时点为 `t0`，原已开启时也以本次确认时点起算，记录实际时间及关联时区。保持该设置生效，自 `t0` 实际经过2分钟（120秒）后再检查告警；不从启动 App、任务开始或未知的历史开启时间起算，也不在检查前关闭侦测、恢复设置或停止 App。执行方依据可靠时钟计算剩余等待，可将期间导航、观察及模型处理的实际耗时计入已过时间，不能按回合数或模型平均耗时估算已经等满；需要显式等待时按实际支持能力补足剩余时间，不无限等待或机械叠加额外2分钟。计时无法证实时保留等待未验证。
3. **检查对应告警**：等待完成后进入同设备告警列表，核对当前日期/时区及实际选中日期，按页面实际能力刷新或重新进入查询，核对 `t0` 后对应时段的声音事件、事件时间与类型，记录查到或未查到。旧日期、开启前的记录、区域入侵或画面变化不能证明本次声音告警正常；消息推送、事件生成和视频可播放仍按本条预期分别核验。记录观察期间实际声音刺激及来源（若有）；现场声源尚未核实时，仍完成可独立执行的开启、2分钟等待和查询，不无限等声源。仅有“已开启 + 等满2分钟 + 无记录”而无有效声音触发证据时，只能记本时段未观察到声音告警、触发能力未验证，不能直接判漏报；触发及观察证据完整时按本条预期判定，不把2分钟擅自推广为所有声音告警的性能阈值。
4. **保留哭声视频断言**：原 8.30 正文指定哭声侦测事件，声音侦测与独立哭声侦测是否共用配置须据实际功能核实，不能只凭名称相近认定相同。普通声音告警可记录本次新增检查结果，但不自动满足原哭声视频断言；确认真实哭声事件后播放对应视频，核验原文所列音画要求，需人工评价的部分按本轮安排留待人工。既有真实哭声视频可覆盖原视频质量检查，但不能替代本次开启、等待及新告警检查；未取得目标视频时保留该部分未验证，不把设置成功或查询完成写成音画通过。告警检查结束后沿用本轮已确认的设置保持/恢复及 App 收尾安排。
## 声音侦测状态与最近七天告警
适用于用户针对 `1ff4c406-14a2-40b6-968f-75fb5e4bf3c2` 为1.14“7天挂测设备异响检查”补充的顺序：先查看声音侦测是否开启，再检查最近7天声音告警。此处查询已有历史，不继承8.30的开启及120秒新触发安排，也不复用12.24的云/卡存时间轴、颜色空洞或每日事件数要求。
1. **先核当前声音侦测状态**：确认同一目标设备，从其设置页按实际加载内容定位“声音侦测”，首屏未见时按 [设置页查找规则](#设置页查找与到底确认) 继续；进入实际详情，读取启用状态及可见配置，不能以主列表入口、指示灯开关或历史告警反推已开启。用户本次仅要求查看，保持声音侦测及灵敏度原值，不自动开启、调档或先关再开。关闭、入口未定位或状态不可读时记录具体情况和原开启条件的缺口，继续可独立查询的七天历史；当前关闭不代表过去无记录，当前开启也不证明七天内持续开启。
2. **固定七天范围并逐日查看**：以开始查询时的可靠日期/时区确定最近7天，未另指定时按当天及前6个自然日列明日期，当天只查至本次已过去的查询时点；用户明确完整日期或滚动168小时口径时沿用，不能将部分当天冒称完整七天挂测。进入同设备告警页，按实际可用的“声音/声响”等筛选核对事件类别，未提供筛选时依据实际事件类型查找，不用“全部”列表的一屏代替。逐日选中并回读日期，等待记录加载，按可用分页或列表滚动查看该日范围，查询仍有新记录时继续，明确真实已查时段及末尾；一条记录、日期栏出现七天或仅查看今天均不证明七天覆盖。嘈杂环境按原要求重点核对夜晚，同时保留其他时段的覆盖，不虚构固定夜间时段或忽略白天。历史保留不足、无权限、加载失败或分页受阻分别记录，不等待未来7天、改设备时间或补造历史。
3. **分别记录告警与异响证据**：按日期列出实际查到的声音告警时间、类型及可核实数量/范围；只有该范围已查完整且明确无记录时才写“未查到声音告警”，未查或不可访问不填0。对疑似异常记录按实际可用入口核对对应音视频及声源资料，关联设备、事件日期和时点；可靠核听或交人工确认是否为设备自身异常声响，不能仅以“较大声响”标签判故障，也不能以有声响告警直接否定原“无异常响声”预期。无告警同样不证明过去没有异响、侦测有效或没有漏报，当前灵敏度不证明历史配置。没有可判定声音资料时保留异响性质/来源待核，继续其他日期，不把查询完成写成无异响通过。
4. **保留原挂测条件及收尾**：原绑定、在线、挂测设备声音侦测开启、另一监控设备对准挂测设备且也开启声音侦测、连续七天含夜晚的范围均保留，需原挂测结论时另核可靠历史起止、配置及对应观察资料。第二监控设备身份和布置尚未确认时，记录缺项，不将列表中任意另一台离线设备直接当作该监控机；这些缺口不阻断本次已具备条件的状态读取和七天历史查询。分别交付当前设置状态、逐日告警覆盖/记录和原异响判据的未验证范围，不以本次历史查询替代完整七天挂测。完成可做项后沿原强制停止App及下一条前核对主/前缀子进程的安排收尾，本条未改设置不新增恢复动作。
## 编码参数互斥与完整核验（9.139）
本条验证“码率/帧率/I帧间隔参数组”与“AOV/智能编码功能组”的互斥及默认恢复；AOV 与智能编码可同时开启，不要求彼此互斥。第二轮用户指定目标设备“设置 → 自定义码率参数”；上轮实际进入的入口名为“自定义编码参数”，当前按实际标签与编码字段核实可操作目标页。不同运行的进入证据不可互相倒填：第二轮只读设备能力集原始Config并未进入参数操作页，不能以该页取代设置入口或据此判互斥通过/失败。按以下阶段对应原步骤，完成检查后才停止 App；按 [两次重置提示分支](encoding-playback-feedback.md#9139参数变更后的两次重置提示分支) 保留完整提示和两分支回读，不在入口偏离或参数修改后提前收尾。
1. **读取基线**：先读码率（如有平均/峰值分别记录）、帧率、I帧间隔及两个开关，页面有 `gop设置` 时核实与本条 I帧间隔的对应关系后进入读取。当前值与可信默认依据分别记录，不能把本次首次读到的1000、1250、15等数值直接认定默认，也不为补默认依据新增恢复出厂。缺少可信默认只影响默认比较，不阻止三项读取及可独立完成的开关核验。
2. **参数修改与自动关闭**：按原文任选一个实际支持的参数改为合法且不同于原值的值，不强制修改全部三项或遍历所有值。为观察要求的自动关闭，先确认两个功能的可观察前态，在本条已授权开关操作内建立开启条件。变更参数并触发保存/应用后，先读取当前弹窗全文，与原预期“设置此功能将会关闭AOV和智能编码功能”比较，确认后完成保存并重进回读参数及两开关；不能先保存离页再核已消失的提示。原已关闭而修改后仍关闭的项，不能声称发生自动关闭，不手动关闭来冒充自动互斥。前态无法建立时保留对应关闭转变未验证，不扩大操作范围。
3. **分别开启并完整回读**：AOV 和智能编码各自的恢复分支，均须在本次已保存有效参数变更的前置下检查。有可信默认时选择合法非默认值；无可信默认时选择合法且不同于变更前的值并保存回读，继续测弹窗、开关及三字段，仅默认恢复比较保留待核，不以无法证明非默认为由省略两分支。前一功能已恢复参数后，后一分支重新建立原文允许的任一参数变更，不能直接开第二个开关并把无变更时无提示当作触发过恢复。分别开启目标功能后，在确认及离页前读取当前完整提示，与原预期“设置此功能，码率、帧率、I帧间隔设置将恢复成默认值”比较；确认开启后逐项进入回读码率、帧率、I帧间隔，有依据时与各项可信默认比较，再进入下一分支。不能只读被修改的那一项；初始已处于默认的项可验证仍等于默认，不能据此证明发生非默认到默认的转变。文案只列部分参数时保留差异，仍读取其余两项；某一项打不开或缺默认依据时记具体缺口，继续其他可读项，不把未查 GOP 当作受阻。
4. **关闭及收尾前核对**：分别关闭 AOV、智能编码，核对原文“不需先校验三参数即可直接关闭”的逻辑与状态反馈。返回或停止 App 前，核对参数修改、两开关自动关闭前后态、两次开启各自的三参数回读、完整提示及关闭操作是否均已覆盖；仍可打开的未查字段或分支应补做。已有失败与真实未验证项分别保留，按本轮恢复及收尾安排记录末态；不因发现文案差异就结束，不以补测为名增加全部参数变更或相邻用例的实测码率、挂测和直播断言。
## 编码组合录制与码率判定（12.14）
适用于本轮用户针对任务 `eeafe931-ae71-41ef-91a4-bfed4d4a547e` 补充的12.14“码率测试”。设备设置与直播清晰度路径是用户新确认的操作要求，不是旧 trace 已完成的事实；原适用条件、像素档判据及收尾仍保留，不串入9.133的所有分辨率切换或9.139的互斥专项。
1. **设置智能编码与实际编码格式**：目标设备“设置”加载后，在列表内继续向下查找并打开“自定义编码参数”；未见时按 [设置页查找规则](#设置页查找与到底确认) 继续，不在“画面与声音”未见就结束。读取初态，开启明确属于“智能编码”的开关并核对必要保存、回读；已开启则核验并保持，不把相邻AOV的标签/状态混记。先选择 H265、完成其高清和超清两段后再选择H264，每次确认实际选中及保存生效。切换编码或清晰度后再次核对智能编码仍开启，不能只在第一段前打开一次就假定所有视频前置相同；若状态确有变化，在本条授权范围内重新开启并复核，真实冲突则保留受影响组合及反馈，不用手动固定码率替代智能编码，也不增加 AOV、恢复出厂或默认值验证。
2. **在直播页依次选择四个组合**：按 `H265×高清 → H265×超清 → H264×高清 → H264×超清` 执行。每种编码返回同设备直播，在实际视频区域唤出清晰度入口并依次选择高清、超清，按 [短时浮层规则](transient-controls.md) 及时完成点击；不能点下方面板拖柄后仅凭未见控件结束。分别核对四组合的选中反馈、实际播放及对应码流。编码格式来自设置，采样清晰度在直播页切换；9.133在设置页读取/修改设备分辨率的路径不能代替本条清晰度操作。记录每段实际视频的 codec、宽×高及可信像素档映射，不把“超清/高清”、设备型号或一次配置读数直接等同于800w/500w/400w/300w/200w。选项不存在或切换未生效时记录该组合缺项，继续其余可做组合，不把其他组合复制计数；不要求一台设备遍历原文列举的全部五档像素。
3. **每段独立完成App内录像5分钟**：本轮明确四段均在App直播页完成，RTSP等外部码流只作测量补充，不替代业务录像。按用户右下角线索，在当前直播布局定位实际录像按钮，核实标签/图标与点击后录像计时或录制中反馈，不能以声音开关或拍照按钮替代。实际点击开始并确认后，以可靠时钟记录起点和截止时间，持续完整300秒，再实际点击停止并确认保存；单次短等待未满时继续剩余时长，未尝试等待不能写为等待受阻。切换编码、清晰度前先停止并保存本段，不能中途切档、复用一段或用等候回执代替成片。可取得素材时进一步核验媒体有效时长，短于300秒不算完整5分钟；超过300秒须按实际时长计算均值，5分钟总量另取有明确边界的连续300秒窗口，不能把整段超长总量直接比较。文件名、模型耗时、App录像图标或自动化录屏总时长均不能单独证明本段完整。缺少提取或分析能力不跳过仍可做的四段App录像，开始、计满、停止、保存及媒体核验缺项分别记录，沿本轮恢复与强制停止 App 安排收尾。
4. **采集来源与执行分工**：逐段取得App录像及其实际来源；需要外部可测码流时只补充同设备对应时段的定量分析。App录像须确认与所测设备直播码流对应、未被重新编码，不能只因存到相册就视为摄像头原始输出。ARTEMIS/scrcpy 的 Android 屏幕录像编码的是手机界面，不能用于本条摄像头码率判定；设置标称码率和直播瞬时速率也不能代替整段实测。执行端不支持提取或解析时，保留已实际完成的App录制、计时、保存结果与素材位置，由已授权宿主按实际序列号、文件访问能力完成提取及分析，不给 Flash 编造 ADB、媒体分析或文件工具，也不新增唯一 SDK/工具前置。素材尚未取得、无法解码或同源性未证实时如实报告对应测量缺项，不猜数值。该条视频与码率表是用户指定交付物，可写入本条提示词；通用屏幕录制和归档要求仍留给 Codex。
5. **逐段计算和输出平均视频码率**：用实际媒体解析能力取得该段所测视频流的有效字节数 `B_video`（排除音频与容器开销）及有效媒体时长 `T`，计算 `平均视频码率(Kbps)=B_video×8/T/1000`，说明视频流选择、时间边界及单位。多视频轨时明确实际被测轨，不能把全部轨相加当单路。文件总大小或容器整体 bit_rate 只能标为含音频/封装的文件总平均码率，未经等价性核实不能替代上述结果；仅对已确认是纯视频码流的原始素材可直接以其有效总字节计算。峰值须另用有效码流样本及有依据的统计窗口测得并说明方法，不能用均值、最大配置值或单个最大帧直接代替；原文未给统计窗口时保留方法口径待核实，不擅自新增固定窗口判据。
6. **按真实像素档与场景分别判定**：每段输出组合、智能编码状态、实际 codec/尺寸、像素档依据、场景、起止及有效秒数、视频有效字节/总文件字节的区别、实际素材路径/来源、平均Kbps、对应阈值、均值判定，以及峰值/5分钟总量的结果或具体缺项。均值阈值按下表选择，不凭 H265/H264 自创新阈值；像素映射尚未核实时仍可输出实测值，但合规判定保留未验证，不能套最近档。平均与峰值使用 `≤`，总量区间两端均严格排除。原表使用 Kbps、MBytes，保留原单位并说明换算；字节范围或 MB/MiB 口径有歧义且影响边界判定时列明待核实，不能静默换算后改阈值。
| 实际适用像素档 | 平均码率上限（Kbps） | 峰值上限（Kbps） | 静态5分钟总量（MBytes，开区间） | 动态5分钟总量（MBytes，开区间） |
| --- | --- | --- | --- | --- |
| 800w | 3072 | 5120 | (56.5, 90) | (112.5, 180) |
| 500w | 2048 | 3072 | (37.5, 56.5) | (75, 113) |
| 400w | 1536 | 2560 | (30, 45) | (60, 90) |
| 300w | 1024 | 1920 | (24, 36) | (48, 72) |
| 200w | 700 | 1024 | (13, 18) | (26, 36) |
7. **均值交付与完整用例覆盖分开**：本次明确四个组合各录5分钟并报告均值，不将“均值达标”写成整条原用例通过。原峰值要求草地等丰富画面；原给定片源可用于平均码率，使用时摄像头画面须全覆盖片源且避免反光，5分钟总量原文只是建议使用实际场景，不将某一种片源或草地升级为所有均值录制的硬前置。原静态、动态各5分钟总量断言分别保留：混合动静的一段5分钟不能同时当作完整静态与动态窗口。若本轮只具备四段某一场景素材，输出该范围均值与可判项，另一场景及未测峰值明确未验证；确按完整原范围分别采集时，按真实适用组合安排独立场景窗口，不静默扩大为所有五种像素档的全排列，也不自动改为仅人工判定均值。
8. **按实际录制数量预留总预算**：基础四段的业务录制时间已是 `4×300=1200秒`，另计设置/切换、加载、保存、提取、分析、有限恢复和收尾余量，按 [长时任务规则](#长时任务预算与实际计时) 核对实际生效的单条/批次/全局时限。四段流程可按实际估算使用本条 `{"timeout_seconds":3600}` 作为有余量示例并保留其他已确认字段；若完整静/动态覆盖需八段独立窗口，仅业务录制已2400秒，预算应重新估算，不能机械继承1800秒或认为同一示例对所有范围都充分。录制期间按可靠时钟、媒体时间与实际状态核验，不按模型平均延迟缩短300秒，不因没有新UI步骤中断有效录制；宿主提取分析另有编排时明确交接与最终合规结果由谁完成，不能在素材未分析时直接报整条通过。
## 最近七天云存卡存空洞检查
适用于用户针对 `ccd4adcb-fe82-4050-9c8a-319395d333e7` 补充的12.24检查范围：查看目标设备已有的最近7天云存、卡存录像时间轴。下面的颜色口径由本轮用户确认，不作为旧 trace 已发现空洞的证据，也不推广到其他 App。本轮又明确须在云回看使用左下日期选择最近7日，抽查实际告警视频并播放，按 [最近7日云告警补充](encoding-playback-feedback.md#1224云回看左下日期与最近7日告警抽查) 与本节双存储空洞检查分别完成，不能以时间轴或一日快放替代告警视频。
1. **先确定七天范围，查看已有历史**：依据可靠当前日期/时区及 App 日期选择器明确具体起止，不从识别冲突或未经核实的摄像头OSD年份推算。未另指定时按执行当天及前6个自然日逐日列明，当天只查至已过去的可查询时点；说明此日期口径，用户明确滚动168小时或其他边界时沿用。不能把七个日期等同完整168小时挂机，不能在本次交互里等待未来7天或用同日多次查看冒充多日。保留原7×24小时、每天10事件原文，但先执行本轮可独立完成的历史检查，不因没有新挂测或事件台账直接停止。
2. **云存、卡存分别定位与核对状态**：确认同一目标设备，进入云回看并核对实际选中类型；卡回放入口未见时沿本轮移动爱家已确认线索，在云回看后观察实际存储类型切换入口，再选择卡存。不假设固定坐标或默认类型，切换后重新确认设备、类型、日期。分别读取实际可见的存储状态、历史保留范围及录像模式/计划；不续费、开通云服务、格式化卡、清空录像或擅自改录制计划来补历史。无卡、权限/加载失败、服务到期、历史保留不足或入口未定位，分别记录实际反馈、可查范围和受阻项，不写成设备不支持或整侧无空洞；一侧受阻继续另一侧。
3. **逐日覆盖实际录制时间轴**：两种存储各检查七个日期，选择后回读已选日期，等待对应录像轨段实际加载。按时间刻度、选时指针和实际缩放/拖动能力查看该日已过去的应录制区间；先小幅操作确认方向和选中时间变化，再分段推进，保留相邻时段重叠以免漏查。有窄缺口时用实际支持的放大/缩放复核，不发明固定像素阈值或最小允许空洞时长。单屏、一天快放、“暂无告警”或日期列表出现七天不证明逐日已查；粗尺度未见白段不能保证不存在更小空洞，按实际刻度与覆盖报告。导航仍在推进时继续，真实预算、加载或交互受阻则说明已查/未查区间，不能以零空洞代填未查日期，也不要求把七天录像按原速全部播放。
4. **按用户颜色定义标记空洞**：仅对已加载的实际录像轨段判断：在应录制期间出现的纯白区段按本轮口径记为空洞；灰色或彩色轨段均为正常有录像显示，不能把灰色当空洞。视频画面灰白、页面背景、刻度线间留白、未加载占位与录像轨段颜色是不同对象。先有限等待/刷新或重新选日以排除未加载，确认区段及边界；正常颜色仍须另核播放，不能凭灰色/彩色就宣布可正常回放。对已见白段保留现象，不将“还能播放”直接抹去时间轴显示空洞；实际录像是否缺失及根因分别核实。
5. **以历史应录制范围解释白段**：结合实际连续/事件录制模式、计划、服务/卡可用范围及相关历史资料判断白段是否处于应录制时段。计划外、事件模式未触发区间、未启用录像期间、保留范围外及未来时刻不能无条件算丢录；当前计划不能独立证明七天前也按同一计划录制。历史依据不足时照常记录白段及时间轴覆盖，标记“是否应录制待核实”，不编造历史配置、事件触发或允许丢录阈值，也不让这项缺口阻断其他日期和存储检查。已确认在应录制期间的白段按用户口径报告空洞；仅凭时间轴不能确定是录像文件缺失、索引显示或其他原因。
6. **逐洞定位并核对播放**：记录存储类型、日期/时区、空洞起止、可辨时长、时间轴刻度及是否完整定位边界；跨午夜的区段分别核对相邻日并关联，不重复计数。边界超出已查范围或刻度不够精细时注明未知/约值，不虚构精确秒数。依实际选时能力查看洞前、洞内、洞后反馈，核对选中时间与实际播放时间是否对应，记录无录像、播放失败、自动跳到邻段或实际可播；只看到视频播放不能证明所选白段有数据。灰色/彩色区段的播放异常单独记录，不能改称白色空洞；不因一洞异常提前结束其他独立可查日期。
7. **分别交付逐日覆盖和空洞明细**：按“存储类型＋日期”列出实际已查起止、应录制依据、轨段状态、空洞数量/明细、边界精度、回放结果和未查/受阻范围。两侧均可查时应有各七日的覆盖记录；不能用云存结果代表卡存，或因某侧历史不足把另一侧也跳过。已完整检查且具备判据的范围才写“未见空洞”，缺失日期/区间写未查或不可用，不能填0或整条通过。原事件无丢失与正常播放若要验收，仍需实际每日事件发生记录/独立台账和对应录像逐项核对；仅查时间轴或告警列表为空不证明每天10事件均留存。分别报告本轮历史空洞检查结果、原稳定性断言未验证范围，完成可做检查后沿原要求强制停止 App，不能用原长期条件缺失代替本轮检查。
## 最近十二小时云存卡存空洞检查
适用于用户针对 `fb5bb019-6307-45d6-949d-3958de56a565` 为12.28追加的最近12小时历史检查。复用 [七天空洞规则](#最近七天云存卡存空洞检查) 中的云/卡入口核对、实际轨段加载、颜色口径、历史应录制依据、边界定位及回放核验；只复用共同方法，不继承其七个日期、7×24小时或每日10事件要求。此前12.24七天范围继续保留，不被本条替换。本轮新增卡回看、云回看均使用页面下角放大镜将时间轴调到12H，按 [12H缩放补充](encoding-playback-feedback.md#1228卡回看和云回看分别调到12h刻度) 核对两侧实际显示；12H显示尺度与本节滚动检查窗口分别满足，见到标签不等于查完12小时。
1. **固定同一个滚动12小时窗口**：以开始本次历史核验时的可靠当前时间为 `T_end`，记录时区及精确起止 `T_start=T_end−12小时`。云存、卡存共用此窗口，不在切换存储后重新取当前时间使窗口漂移，也不把最近12小时改成当天00:00起、12个整点或七个日期。窗口末端尚未生成/上传或索引延迟时有限刷新后记录未查/待确认近端区间，不能把结束时点悄悄向前移动、缩短总窗口或以0空洞代填。OSD或设备/App时钟未核实时按可靠时钟与实际日期/时区关系注明歧义，不从异常年份推算。
2. **两种存储分别覆盖，跨日分别选日**：从同设备云回看、卡回放进入实际录像时间轴，切换后确认类型、已选日期和加载结果；“设置→存储卡”显示容量、已安装或格式化按钮只证明管理页所见状态，不能替代卡回放。按窗口与各日期的交集逐段拖动/缩放检查；跨午夜时两日均须实际选中并回读，先核对拖动方向与选中时刻，保留相邻视段衔接，检查窗口起止附近。不能只查看今天、一屏或一天快放后就宣布完整12小时。存储不可用、权限/加载异常或历史不足时保留原请求窗口、实际已查与未查范围，一侧受阻继续另一侧，不推断设备不支持。
3. **沿用户颜色口径逐洞记录**：应录制期间已加载的时间轴录像轨段纯白为空洞，灰色/彩色为正常有录像显示；与视频画面灰白、页面背景、刻度留白或未加载占位分别处理。结合实际录像模式/计划及历史依据核对是否应录制，不将计划外、事件未触发、保留范围外或未来时段无条件算丢录；历史依据不足仍记录白段，注明是否应录制待核实，不停止其余可做检查。逐洞记录存储、日期/时区、起止/可辨时长、刻度精度和洞前/洞内/洞后反馈，核对回放没有自动跳到其他有录像时刻；跨午夜同一缺段关联去重。边界不清时保留约值或未知，不编精确秒数。灰色/彩色仅证明正常轨段显示，播放结果另判；白段实际可播时保留时间轴空洞现象，数据是否缺失另核。
4. **分别输出覆盖与原稳定性结论**：每侧报告相同请求窗口、按日期分段的已查/未查区间、应录制依据、空洞明细、回放异常及实际精度，只有已完整检查且具备判据的范围可写未见空洞。无卡、云服务不可用、历史不足或粗尺度未查部分不填0，也不用云存代替卡存。无需等未来12小时或完整原速播放12小时；检查已有记录时缺少新负载台账不能阻断回看，也不能通过现在改灵敏度、码率或计划来证明过去的负载。原12.28的动态高码率直存、SD卡、实际适用CPU/内存负载、连续至少12小时及无重启/掉线仍独立保留；例举功能不等于设备全部支持。无白洞不能证明当时满足负载或从未重启/掉线，有白洞也不能直接归因重启/掉线。需要原稳定性通过时须另有对应负载、真实连续时长及可靠重启/掉线证据，不以历史回看替代；本次不因此自动新建12小时挂测。完成本轮独立可做项后沿原要求强制停止App，未完成/受阻范围如实报告。
## 第16部分云化AI算法范围与入口
本节按条目区分最新用户范围。**16.1“人脸抓拍逻辑”优先执行以下2026-10-21端侧例外，不应用其后通用云化算法查找与替代限制**；其余原第16部分云化AI用例继续沿用原口径。用户针对 `3664b280-49da-43eb-9bbb-4bcd77afe859` 确认只有目标设备“设置 → AI设置”内算法才计入云化AI，主页面“功能设置”中的人脸侦测属于端侧算法；该架构区分仍有效，16.1最新要求改为核查该端侧算法。本节仅用于本轮移动爱家与目标设备，不据名称推定其他App或设备架构。
**16.1主页面人脸侦测与端侧支持例外**（对应历史 `e00a853e-8460-4e7e-bf0e-bf4bc3a943bb`）：
- 先确认同一目标设备并进入设置主页面，等待内容实际加载。当前可见“人脸侦测”时即可判断入口存在，无需为支持判定继续遍历；未见时按主列表实际进展完成必要滚动、加载与末尾核实。只查该主列表，不进入“AI设置”“AI周界”或其他算法子页补找替代入口，不沿用“主列表未见还须查相关子页”的通用分支。
- 主页面有“人脸侦测”入口，即按用户口径认定支持**本条端侧算法**；灰色、关闭或带“云存储专属”仍属入口存在，分别记录实际启用、可用/服务状态，不把它们当作入口不存在。支持不等于已开启、服务已开通、抓拍逻辑或效果通过。支持后进入已找到的人脸侦测页，只查看本条原要求的逻辑条件/模式，不新增开关、参数修改或付费开通；入口不可点或页面受限时保留查看受阻，不反改支持判断。
- 主列表已加载且必要查找确已完整，仍无“人脸侦测”时，按用户指定口径记录“设备不支持端侧算法，需人工判断”，同时保留已查范围，不再进入AI设置查云化人脸或改测AI周界。未加载、未查完、权限/滚动受阻或预算中断时，记录“主页面入口未确认”及具体覆盖缺口，不能写“没有”或套用不支持表述。
- 支持后继续16.1原“人脸抓拍逻辑”的查看动作、真实前置与判据，入口确认不能代替结果观察；无真实场景、人脸图片或效果依据时分别保留未验证，不新增16.2等其他用例的云化准确率、误抓率或指标。此例外不改变16.10云化人脸启用、16.75车辆负向、16.124电瓶车四项支持，也不改变9.122查AI设置/AI周界关闭全部实际侦测的范围。
- 历史第6、7、15步已显示主页面“人脸侦测”，旧提示要求云化并排除端侧后又进入AI设置。该事实用于解释旧范围与最新用户要求的差异；保留旧运行原始状态和业务判定，不倒填为16.1抓拍逻辑已执行或通过，不修改历史证据。本skill只修订后续规则，不启动设备或重跑任务。
**以下1—7项仅适用于其余云化AI用例，不覆盖上述16.1例外。**
1. **先核对本条云化算法身份与入口**：确认同一目标设备，进入设备设置并打开实际“AI设置”，等待算法列表加载，再核对与本条原用例对应的算法、可见状态和参数；不是看到任意AI服务就认定本条算法存在。主设置页的人脸侦测、同名开关、历史告警或“云存储专属”标签均不能证明云化AI支持、已开启或已产生云化结果，也不能用于替代本条操作与效果证据。不能为凑齐云化测试去开启端侧人脸侦测。
2. **未找到时区分覆盖与支持情况**：设置主列表首屏未见“AI设置”，或进入后首屏未见目标算法时，按 [设置页查找与到底确认](#设置页查找与到底确认) 每次滚动后重新观察，有新条目就继续，确认实际查找范围与可靠末尾，不设固定滑动次数或复用旧坐标。区分“AI设置入口未定位”“AI设置内未见本条算法”与“页面未加载/权限或滚动受阻”，分别记录已查和未查范围。合理查找后未见入口或算法，可说明设备可能不支持云化AI或该目标云化算法，需人工核对；仅缺某一算法不扩大为全部云化算法均不支持，加载受阻也不算已查无此功能。保留本条云化分支未验证及具体原因，不判算法效果失败、通过或自动改为端侧测试，也不凭此自动改写原表适用性。
3. **找到后按本条动作和判据继续**：先读实际状态，原步骤或用户已明确补充要求开启、改参数时，按本条范围操作并核对必要保存/回读；只要求查看且无新增开启要求时不增设开关动作。是否存在、是否启用与准确率/抓拍/告警等效果分别验收；效果必须来自该云化算法及对应真实场景、样本和可核验结果，不能拿端侧结果代替。入口存在不等于已开通、启用或达标；服务或权限限制如实记录，不为补测新增付费开通。缺少效果样本不阻断独立可做的AI设置入口和算法核对。
4. **保留各条原有适用性与指标**：本条入口确认不消除室内/室外、架设、真实标注样本及效果判据的原缺口；16.2中的准确率、误抓率、重复抓拍等指标仍按其原文与已确认适用口径核验，不把室外专用焦距/架设条件直接套给室内云台机，也不向其他16.*用例追加16.2全部指标。云化目标尚未确认时，不用端侧开关状态或未获得统计值推断云化算法优劣。完成可做项或受阻退出后沿原约定收尾，新路径不倒填旧运行已完成。
5. **16.10先确认并开启人脸-AI**：用户针对 `2bca40cb-1d1e-4644-a349-169e6e97dda8` 补充确认开启步骤。先进入同设备“设置 → AI设置”，定位用户所指“人脸-AI”对应的实际云化人脸算法，记录实际标签、初态及可用状态，不预设更深子页名称。关闭时开启并完成页面实际要求的保存，依据状态变化及重新进入/可用回读确认仍已启用；已开启则保持并核验，不为凑动作先关闭再开。入口点击、操作已发出或一次成功提示不能单独证明人脸AI启用，“翻转视频源”启用更不是该算法开关。未找到、启用失败或权限/服务受限时按上条查找与支持规则记录，继续独立可做的原操作，不能换开端侧人脸侦测。原真实设备倒装、设置旋转视频源、查看人脸上报图及云存储的要求保留：在本次云化人脸已启用且翻转仍生效的真实倒装条件下，按实际反馈取得可归属于该设备、该算法及该有效时段的人脸上报图片和对应云录像，核对方向后再按既定安排恢复。启用前的旧录像、声响告警图、无可辨人脸或方向的灰白画面均不能证明本条效果；不靠固定等待或任意告警补证。缺少真实倒装/新素材时分开保留条件和效果缺项，不让这些缺口替代已获准的人脸AI查找、开启和回读，也不把设置成功写成整条通过。观察结束后保留原翻转恢复及强制停止App收尾，人脸AI初态、末态及本轮既定保留/恢复安排分别记录；本补充不扩为其他16.*用例一律开启或追加16.2准确率指标。
6. **AI车辆识别与AI周界分别处理（含16.75）**：用户针对 `31ac0cd2-2193-42f2-98dd-c26bb01e9796` 明确本条AI识别不是AI周界中的功能。沿本轮已确认的“同设备设置 → AI设置”查找实际对应的AI车辆识别算法及开关，记录实际名称和状态，不预设更深页面或坐标；“AI周界”内的汽车目标、区域入侵、越界侦测，以及普通移动侦测开关/区域/灵敏度，均不是该目标算法，不将它们继续列为本轮车辆算法候选，也不能借其开启、区域配置或成功反馈证明目标支持与生效。设备设置首屏未见时继续核对列表及AI设置实际内容，按前述滚动、加载和末尾规则记录查找范围；充分查找仍未见对应开关，可说明设备可能不支持该AI车辆识别算法、需人工核对，受阻/未查范围另列，不直接断言不支持、判效果失败或改测AI周界。找到后按本条原动作核查状态与效果，不自动追加开启或修改无关设置。16.75保留原“设备具有前端AI检测能力”等条件及真实区外车辆负向要求，不据“前端AI”字样将周界功能等同目标，也不臆断实际运算架构；目标能力、启用情况、检测区域和车辆实际区外位置均须有对应有效依据，未经共享映射确证的普通移动侦测全画面默认框不能当作目标算法检测区域。原允许的移动侦测区域复用须先确认目标车辆算法身份，并有可信依据证实同一配置实际作用于该算法及其映射范围；这仅覆盖区域参数证据，不证明目标算法支持、已启用或效果，也不能重新将AI周界等同目标算法。没有真实车辆经过或对应记录核对时，空画面、空事件列表不证明“不识别、不记录”通过；不新增区内识别成功前提、全档遍历或其他算法准确率指标。算法身份/开关未确认与缺少真实刺激分别报告，完成可做核查后沿原安排收尾。
7. **AI电瓶车识别与四项设置支持（16.124）**：用户针对 `4e1d97db-c0f5-4772-86f6-2536148e7de6` 明确本条AI电瓶车识别不是AI周界中的功能。先在同设备设置中沿已确认的“AI设置”查找实际对应的电瓶车算法及开关，记录实际标签、支持来源及可用状态；AI周界中的非机动车/电瓶车目标、区域入侵或越界侦测均不作为本条算法候选，普通移动侦测、端侧功能或通用“车辆识别”条目也不自动证明目标电瓶车算法支持。未见时按前述设置列表和AI列表的实际进展继续查找、核对加载及末尾，合理查找后仍未找到对应开关，可说明设备可能不支持该AI电瓶车算法、需人工核对；查找未完、加载/权限受阻分别记录，不断言不支持。通用车辆识别显示“去开通”仅覆盖该条目的服务状态，不证明电瓶车算法存在、缺失或必须付费，不为补查新增付费开通。确认目标算法身份后，按原步骤仅查看并分别核实四项支持：电瓶车检测区域画框、侦测功能开关、侦测灵敏度设置、侦测区域设置，保留原四项而不因画框与区域可共用就合并漏项。可明确映射到本算法的界面、能力或有效配置作为支持依据；确证共享配置的同一控件可支撑多项，不要求四个专属入口，也不能仅凭通用移动侦测有这些控件就判支持。某项缺依据时列该项未验证，继续其他可独立核对项；当前开关关闭不等于不支持。原仅要求查看，不新增开启、修改灵敏度/区域、保存遍历、真实电瓶车触发或准确率测试，也不移入16.75区外负向条件或另造非电梯场景分支。完成可做核查后沿原约定收尾，不把未定位算法改判为四项功能失败或通过。
## 设备自动维护最近日期检查（9.31）
本节依据用户针对 `2e1d02c2-6134-416e-b45a-92563b85f3c1` 新确认的路径与判据，仅用于本轮9.31“设备支持按需上传日志”（分类为设备自动维护）。本次执行范围改为读取维护日期的显示情况；原预置、步骤与预期保留为来源，原开启日志、设置维护时间、真实维护周期及设备重启/日志上传等不再作为本次只读检查的自动门槛，不推广到其他维护或日志用例。
1. **先点顶部设备图标，后找型号**：进入目标设备设置并等待加载；已经向下滚动时先回到实际最顶部，重新定位设备外观图标并实际点击，观察是否进入设备信息/详情页。图标节点无文字或自身clickable=false时，核其可点击父容器和当前图标所在的实际点击区域，不因此跳过；避开相邻的昵称编辑入口。型号字段应在信息页查找，不因设置主列表当前无型号就连续下滑或结束。昵称、位置、共享状态、固件版本及主列表“开发者选项（正式版本不会存在此功能）”分组均不能代替真实设备型号或已开启开发者模式的证据。顶部图标未打开时有限纠正并记录反馈，不直接宣称字段不存在。
2. **对真实型号连续五击**：读取目标设备实际“设备型号”标签及对应值，按当前布局定位该字段的可点击区域；使用执行端实际支持的一次连续5次点击（例如click的times=5）或等价短序列，避免拆成五轮模型问答。不点昵称、设备图标、固件值或主列表分组冒充五击，不固化坐标或编造点击间隔阈值。动作后核实开发者模式提示/新入口，按实际反馈进入；手势回执本身不证明模式已出现。无反馈时核命中位置与当前页面并有限纠正，不无限重复。
3. **进入配置只读日期**：在开发者模式实际开放后，定位并进入“设备自动维护配置”，等待数据加载，读取“最近维护日期”的实际标签、原始显示值及设备身份。页面可滚动且目标尚未出现时继续在该配置页查找；未定位字段与已读字段为空分别报告，不回到无关设置反复泛查。用户确认路径用于新稿，不能倒填历史执行已走通。
4. **按日期是否显示判断**：字段加载完成且显示可辨日期值时，本次日期显示检查满足；不要求日期等于今天、不新增维护间隔、新鲜度或固定格式校验。字段明确空白、占位符、暂无/未维护等无日期状态时，保留原显示并记录本次未显示日期，不擅自执行维护来补值。无法进入、字段未定位、持续加载、报错或文字不可读时为受阻/未验证，不能据此断言设备没有维护日期。含义不清的值照录并保留待核，不从其他日期、日志时间或系统时间反推。
5. **本次完成与原机制分开**：不修改维护开关、开始时刻、周期、日志获取，不触发立即维护/重启，不改时钟、断网或解除绑定，也不等待跨日/数日来凑原判据。默认开启、1:00:00–3:59:59、1–7天/默认7天、重启与日志上传、语音/云台行为、离线未绑定仍执行等原预期只作来源与未验证范围。日期存在不证明这些机制通过；本次路径和读取已完成或确有具体受阻且有限纠正无效后，沿原强停App及执行方进程核对安排收尾。单条Flash及既有配置保持，不为只读日期增加长时预算或录屏要求。
## 用户确认路径与人工判定采集
以下路径由本轮用户针对移动爱家 V99.0.0、长虹SC52034明确确认；按该版本与目标范围使用，不推广到其他 App 或未经确认的布局。用户确认与历史 trace 已走通分别记录。执行时仍以当前页面和实际选中反馈核对，路径不匹配时有限重新观察，不猜坐标或将近义选项自动等同。
- **设备信息入口与型号（9.2）**：用户确认设备信息需在目标设备“设置”页最上方点击设备图标查看。先等待设置内容加载，若已滚动则回到顶部并重新定位设备图标（设备外观图），点击后观察打开的实际页面及字段，读取本条所需的型号原值；不预设新页面的准确名称、字段全集或坐标，也不在主列表中反复寻找字面完全一致的“设备设置”行。9.2将实际型号与本条已取得的独立厂商型号“长虹SC52034”按既有逐字规则比较，品牌前缀等差异如实保留，比较口径未明确调整前不擅自去品牌、归一化或改预期；设备昵称、卡片标题、外观和固件版本均不能替代型号字段。入口未打开或未见目标字段时，有限重新观察并记录入口结果、已查范围与型号未验证；用户确认路径不等于历史 trace 已读取型号或验证通过。
- **设备日志管理与人工核对（9.69）**：按用户确认的“目标设备设置页 → 最上方设备图标 → 详情 → 设备日志管理”进入，等待实际内容加载；不以设置主列表泛查或“设备检测/网络检测”代替日志入口。先记录初始档位及日志获取状态，存在日志获取开关时按本条要求开启并确认。依据实际可用控件完成两次相对前态的档位变化，每次均核对保存/回读并取得该次对应的完整日志获取地址，记录第1/2次、可读档位标签或位置、设备及变更/取址时点。无变化的点击不算调整；不追加全部档位遍历，不把刻度序位推成内部等级，未知映射留给人工，不阻断独立采集。通过实际可用的复制、分享或下载入口提取完整地址，不能用省略地址的截图冒充已取得完整链接；若两次显示同一地址，保留各次关联，不能虚构两个不同链接。地址可下载且宿主具备实际能力时，及时按各次关联保存对应文件；地址取得与文件下载分别记录，下载失败或无法区分对应内容时注明缺项，不宣称已留存日志。两次采集结束后按上述诊断设置恢复规则处理，不在取得对应资料前恢复，不用单独收尾恢复冒充漏做的测试调整。本轮日志正文等级与 App 档位是否一致交人工核对，保留原判据和待判状态；自动只报告操作及资料采集范围，不因两次调档、链接或下载成功判业务通过。
- **功能设置检查后查询固件升级（9.21）**：按原七组范围读取本次升级前设置，完成可读取项后，回到同设备“设置”并查找、打开实际“固件升级”入口，等待页面加载及版本检查结果；页面有实际检查操作时按界面查询，不只读主列表的当前版本号或有无提示标记。未读设置列为覆盖缺口，不一律视为用户未提供；缺口不阻止独立查询版本，也不能据此声称基线完整。分别记录当前固件、可升级版本（若有）及查询结果：有新版本时记录目标版本及页面反馈，按本条已有 OTA 执行安排推进真实升级，并在完成、设备恢复后回读原设置逐项比较；本条查询不扩展为部署外部包、刷机或修改 OTA 服务。明确显示已是最新或暂无新版本时，保留已完成基线与查询结果，说明当前无可用升级、OTA 及升级后保持未验证，不循环查找或以 App 重启代替升级。页面未加载、检查报错或入口未定位时记录版本检查受阻及范围，不写成已是最新或没有升级包。升级前未读项目与升级后未比较项目分别保留；只有版本检查完成不能判原七组设置升级前后保持一致，发现新版本也不等于已升级完成。
- **固件包版本字段与格式（13.13）**：用户针对abeb226f明确确认，本条“固件包版本”就是目标设备“设置 → 固件升级”页面的设备版本；页面采用“当前版本”标签也为有效取值，不再以缺少字面“固件包版本”字段拒绝判定。进入实际升级页并等待内容加载，记录目标设备、页面标签及版本原串；同页有当前/可升级两个版本时分别标明，本条按已确认的当前版本取值，不混用App安装版本、设备昵称或其他设备版本。保留原预期“3段式、纯数字、每段最多5位”：只对版本值核对两个点分隔的三个非空数字段，每段1至5位；`1.0.01`为1/1/2位，符合要求，原未禁止前导零，不转整数抹去`01`或据此判失败。本条仅查看并校验格式，环境元数据中的预期固件版本不自动增加相等断言，也不要求外部包下载/解包、OTA升级或升级后设置比较；“当前已是最新版本”不是格式判据，有无新版本不阻断读取当前版本。实际版本未加载或不可读时记录受阻，仍按原约定收尾。此字段映射限本轮已确认的页面和13.13范围，不推广为其他信息字段可任意近义替代。
- **自定义编码参数与码率（9.101）**：按用户确认的“目标设备设置页 → 下方‘自定义编码参数’”进入，等待实际内容加载；首屏未见时在设置列表继续向上滑动查看更下方，每次滑动后重新观察，不把“固件升级/设备检测/流量播放提醒”所在一屏当作已查到底，也不以“画面与声音”“AI设置”或直播 HD/清晰度切换代替码率入口。按实际页面确认码率字段、作用码流/通道（如有）、单位及合法范围，记录初值；具体目标优先沿用原文或用户最新确认值；本轮9.101已明确VBR平均2000/峰值2300、CBR平均2000，并要求每模式直播标清/高清/超清各录30秒，按 [六段录像补充](encoding-playback-feedback.md#9101两种码率模式与六段30秒录像) 编写，不再任选其他值替代。仅在确实未指定数值的其他任务中，可选择该页实际支持且不同于当前的有效值；不能把本条数值、单位或档位固定到所有设备。修改后核对实际输入/选中值、必要保存反馈及再次进入后的回读，避免同时修改无关编码参数。原判据要求设置码率后智能编码自动关闭，须分别记录修改前后的可观察状态或对应有效证据；智能编码入口沿本轮用户确认的“自定义编码参数”查找，具体控件及状态以实际界面为准，不能手动关闭智能编码后声称自动互斥成功；修改前已关闭、修改后仍关闭也不证明发生自动关闭，互斥转变保留未验证。智能编码状态无法取得时保留互斥断言未验证，继续可独立完成的码率设置及回读，单独设置成功不等于整条通过。厂复后默认开启仍作为独立分支保留，不用当前开启、手动重开或恢复码率代替，也不为补证擅自恢复出厂；原文1.48/1.49旧版注记不证明当前 App 的支持情况。完成修改状态下的观察后沿用本轮恢复/收尾安排并记录末态。入口未定位时保留已查/未查范围，不从错查候选页推断设备无此能力。
- **侦测关闭、AOV 与退出后直播检查（9.122）**：本轮最新顺序按 [全部侦测关闭与60秒退出](encoding-playback-feedback.md#9122全部实际侦测关闭aov与退出后返回)：先核对设备实际存在的全部侦测/跟踪与相关AI功能，进入实际子页关闭并保存回读，不能只处理两项或漏掉AI周界、AI设置内相关算法；再到设备设置下方“自定义编码参数”开启AOV，回读后退出App，按实际退出时点计满60秒，再进入同设备直播检查真实出图、播放推进及异常。支持能力不证明开启、设置成功不证明播放正常，设置页等待不能抵扣退出等待，退出状态实际持续时间按可靠时钟核对，不凭模型回合耗时推定。原仍保留的码率修改若需执行，在侦测关闭后、AOV开启前完成，不把历史“任选有效码率”当作本轮必需新增动作；AOV造成参数恢复时记录实际末态，不反复改码率干扰AOV。原真实动/静场景、不启动直播挂测以及本次生成流“正常播放、无快播”仍另列独立范围，60秒退出不代验全部挂测，缺长期条件也不阻断本轮可做的明确链路。直播结果观察后沿既定恢复与App收尾安排执行；不继承9.101的互斥或厂复默认，也不向9.101追加AOV。
- **自定义编码参数中的分辨率（9.133）**：用户确认本条先在“目标设备设置页 → 下方‘自定义编码参数’”查看分辨率，替代原步骤中未适配本轮界面的“画面设置”入口。等待设置内容加载，向下查找并在每次滑动后重新观察，打开实际子页再读取分辨率字段、当前选中值及可选项；有清晰度或码流分组时，分别关联实际所属分组，同一清晰度可对应多个分辨率，不能从“标清/高清/超高清”、直播 HD 标签、画面观感或码率数值反推具体像素尺寸。只查看时保持原值，不因进入编码页而顺带修改码率或开启 AOV。原 9.133 仍要求切换分辨率并查看直播效果：按设备实际支持项完成原要求的切换，每次核对选择、必要保存及重新进入回读，并在该次分辨率仍生效时检查同设备直播，再进行下一次切换或恢复。原列举的数值、分类及切换示例保留为来源要求，不能全部当作本设备已上报能力，不强加全档或清晰度与分辨率的全部组合遍历，不修补原文孤立的“c”为猜测数值；不支持的示例与尚未验证的分支分别说明。原文默认 2304*1296 按原适用范围核对，当前选中或手动改回不证明出厂默认，也不为补证新增恢复出厂。配置回读与原直播“播放流畅、无花屏/卡顿/跳帧/绿屏、音视频同步、声音无失真”分别核验，不能由保存成功推出实际视频流分辨率或音画通过；需要人工听音、音画质量判断的部分按本轮安排保留待判，未获得有效观察的部分保持未验证，不指定唯一测流工具。入口未定位或字段未加载时记录已查/未查范围，不从候选页未见控件推断设备不支持。完成观察后沿用本轮恢复及 App 收尾安排，本条不继承 9.101 的智能编码互斥或 9.122 的 AOV 挂测要求。
- **自定义编码参数中的智能编码开关（9.137；12.29共用入口与实测边界）**：按用户确认的“目标设备设置页 → 下方‘自定义编码参数’”进入，替代原“画面设置”候选路径；等待内容加载，向下查找时每次滑动后重新观察，不以“AI设置”的智能服务或“画面与声音”未见目标推断不支持。定位实际“智能编码”开关，原文已明确它与静态码率压降开关为同一功能；界面采用其他名称时仍核实对应关系，不从近名、能力布尔值或静态配置文本推断可操作开关。先记录原始状态，按原步骤先开启并核对保存/回读，再关闭并核对保存/回读；初始已开启时保持并核验开启态，不为凑次数先关闭，两态观察完成不等于必须发生两次状态变化。在每个被测状态仍生效时，先实际进入同设备直播检查持续出图及花屏、黑屏、绿屏、卡顿等异常，再按实际可用的观察能力采集有效静态场景的实际输出码率，关联设备、码流、分辨率、时段及开关状态，在可比条件下核验“开启识别并降低静态输出码率、关闭后正常输出”的原预期，再进入下一态或恢复。设置页标称/目标码率、输入的1000/1250等数值、开关颜色或一次保存成功均不能当作实测输出及压降效果；不虚构压降比例、正常码率阈值、等待秒数或不存在的测量工具。缺少有效静态场景、实测来源或足够判据时保留具体效果未验证，继续可独立完成的开关操作和两态各自直播观察；开关、直播和真实压降分别验收，不把设置成功或画面正常写成整条通过。具体按 [每态直播补充](encoding-playback-feedback.md#91371229123每个规定智能编码状态都看直播)。原“默认开启”须有可信默认起点或对应资料，当前开启及手动重开不证明默认；缺少默认依据不阻断两态操作，不因补证新增恢复出厂。保留原备注引用的12.29–12.32智能编码要求，取得对应原文时据其补足判据，不编造其内容或自动扩为执行全部关联用例。本条不要求顺带修改固定码率、分辨率、开启 AOV 或验证9.101的自动互斥；手动码率变更可能干扰开关状态及效果，不能用它代替本条开关操作。完成两态结果观察后沿用本轮设置恢复及 App 收尾安排，入口未定位时保留已查/未查范围及未完成断言。
- **静态码率压降的本条断言（12.29）**：用户再次确认智能编码开关位于设备设置页下方“自定义编码参数”；按上条共享的定位、保存回读、真实静态场景两态输出、默认依据及恢复边界编写，开启和关闭顺序来自12.29本条原步骤。另保留原能力集及配置项上报/支持核查：通过执行端实际可用的页面或诊断来源读取对应值及来源，不将开关可见、当前开启或能力布尔值等同于已核完上报、可信默认或压降效果；缺上报/默认证据时分别保留未验证，继续可独立完成的开关操作。开启时先进入直播观察画面并采实际静态输出以核验识别和压降，关闭后在仍关闭时再次进入直播观察花屏等异常并核验正常输出，再按既定安排恢复；两态直播不能合并成末态一次，按 [每态直播补充](encoding-playback-feedback.md#91371229123每个规定智能编码状态都看直播) 分别记录；可比场景、码流和分辨率应关联，不用标称码率或纯屏幕录像代替实测，不编造压降比例、正常输出阈值或固定采样时长。本条不要求12.14的H265/H264及超清/高清四组合和每段5分钟，也不引入AOV、固定码率修改、9.101自动互斥或恢复出厂。原9.137对12.29–12.32的备注仍保留；本轮仅已核实12.29原文，不据此代填其余关联用例内容或自动扩为执行全部关联项。
- **静态码率压降效果的本条范围（历史编号12.3）**：任务1725bc2a的原预置要求设备端能力集上报支持，原动作仅打开静态码率压降开关。沿用户已确认的“设备设置页下方→自定义编码参数”找到智能编码，本轮已确证它就是原静态码率压降开关，不需要另找字面同名的独立控件；读取本条支持依据与当前状态，开启并核对必要保存/回读；已回读开启则核验并保持、继续直播观察，不把额外同名控件未见判为开启缺失，也不借前一任务状态作为本条证据。随后保持开启，实际进入同设备直播检查持续出图及花屏等异常，按 [开启态直播补充](encoding-playback-feedback.md#91371229123每个规定智能编码状态都看直播) 记录；再在该开启状态及真实静态场景下，采集同设备/码流/分辨率的实际输出，按已取得的对应效果规范与有效参照判断压降，标称码率、当前on或灰白直播单帧均不证明效果。原分类提示参考《静态场景码率压降要求》，未取得相关标准或测量依据时分别记录实测与判据缺项，不虚构比例、阈值、固定采样秒数、5分钟或必须由指定人员提供的条件。保持本条开启和效果范围，不自动添加12.29的关闭/默认断言、12.14的H265/H264四组合，或为造参照先修改固定码率/开启AOV；确需额外对照测量时应说明其方法依据及授权范围。缺效果依据不阻断可独立完成的开启和回读，操作完成不等于业务通过；按本轮既定恢复及强制停止App安排收尾。
- **自定义编码参数中的 AOV 开关（9.138）**：按用户确认的“目标设备设置页 → 下方‘自定义编码参数’”进入，未见时遵循上述持续查找与末尾确认规则，不把“固件升级/设备检测/网络切换”一屏当作已查到底。读取实际 AOV 初始状态，按原顺序确认开启、核对必要保存并重新进入回读，再关闭并核对保存/回读；初始已开启时先核验开启态，不为凑次数先关闭，点击回执或支持字段不能替代启用状态。原默认分支“常电设备默认关闭、低功耗设备默认开启，以设备上报为准”继续保留：使用独立且可信的供电类型资料与默认起点/设备上报依据，不从室内云台类型、当前开关或 `support_aov` 反推供电类别及默认值。缺少供电类型或可信默认证据时仅保留该断言未验证，继续可独立完成的开关操作，不为补证新增恢复出厂。原前置条件及备注引用9.114–9.130保留，不自行改写能力条件、编造关联用例内容或扩为执行全部关联项；本条不继承9.122的码率修改、动静场景挂测或直播检查。开关生效与 AOV 后续录制/播放效果分别验收，完成本条结果观察后沿用本轮设置恢复及 App 收尾安排。
- **缩略图模式**：先进入 App“设备”页（设备列表），点击右上角“+”左侧的摄像机小图标，进入实际展示缩略图的页面。3.2按 [顶部下拉与返回更新](#缩略图顶部下拉与直播返回更新32) 先确认列表最顶端，再独立下拉核实刷新；找目标后从中部向下滚一次不能代替。手动刷新结果取得后再做进入直播、退出回列表比较，两条来源分开。默认设备产品图卡片不能直接当作该缩略图；以模式切换反馈确认目标区域，不能因旧记录里产品图不变就判缩略图缺陷。
- **直播控件**：用户确认的轻点直播画面唤出入口与后续运行中确实出现的浮层分别记录。进入直播并确认实际视频边界后，在中心或邻近无按钮区域唤出；入口与当前布局已确认时，按 [短时浮层与连续操作](transient-controls.md) 及时连续点击目标，浮层已隐藏则有限重新唤出，避免每次都等待完整观测后才决定下一点。避开录像按钮、下方控制条、拖柄和云台面板，不固定屏幕坐标；布局变化后重新识别。此分支不要求无关用例切换分辨率。6.5按 [直播逐档五分钟与对应云录像](#直播逐档五分钟与对应云录像65) 逐档真实播放后再查对应录像；内容模糊与播放故障分开判断，不把仅适用于云台/场景比较的可辨参照要求变成清晰度菜单的硬前置。
- **夜视取图与能力分支**：本轮以夜视画面采集、人工判断为交付目标时，先按“设备设置 → 画面与声音 → 夜视”核对当前选项和选中状态；实际存在“智能夜视”时按已确认安排选择并回读。目标已确认为室内云台机、当前夜视页未见“智能夜视”且已核实该页“自动”选项时，按用户本轮补充保留当前已选的“自动”，或选择该“自动”并回读，再返回同设备直播取得本条要求的画面，不仅因缺少智能选项终止独立可做的取图。**不得为继续取图将夜视设为“关”，也不得开启全彩/全彩夜视模式作为替代**；用户没有要求一律强制选“开”。记录实际选项与选中状态，使用“自动”时不能写成已开启“智能夜视”，也不把某次页面未见该项推广为该设备或所有室内云台机均不支持。若可用分支仍无法核实，保留具体原因与未执行范围。3.8还需记录直播画面的日期、时间及时区，进入同设备云回看，在对应过去录像时点播放稳定后再留存一张；3.14仅要求本轮直播截图。两条业务画质/距离结论交人工判断；自动操作和截图采集完成不等于原业务通过。不得为取图擅自遮挡实物、制造夜间场景；“自动”或“智能夜视”配置均不证明红外已触发、画面应为黑白或夜视距离达标。原判据保留供人工使用，缺少现场/测距影响人工结论，不阻止独立可做的配置及取图。若原用例专项检验智能夜视切换、补光或联动等必须由智能模式建立的条件，保留该断言与未验证范围，不能用“自动”判其满足。
- **云回看选时**：先确认云回看类型、设备、日期选中状态、时间轴刻度及过去有数据区。拖动前识别时间轴可拖动区域和选时指针；先小幅试拖并回读选中时间的变化，确认实际方向，再小步对准目标时间，不预设向左/向右、像素距离或固定屏幕坐标。松手后等待实际播放恢复，核对播放日期/OSD或可读播放时间与目标对应。不能只凭刻度移动或有颜色就认定选时/播放成功。取对应直播时刻时不拿其他时段替代；新录像尚未生成、目标无数据或仍不可播放时保留已取得的直播图并注明云图待补，不选择未来时刻或无限等待。
- **直播出图与云台**：云台或依赖画面比较的用例，先确认直播已出图且有可辨参照；若画面灰白、模糊或疑似遮挡，可在已授权的云台操作范围内有限调整方向，再重新观察，不能声称已移除实体遮挡。用户本轮要求的方向验证按上、下、左、右各长按5秒，使用实际支持的持续按压能力并核对持续时间及按钮命中；能力不支持时如实记录，点击不冒充5秒长按。每方向松手后待画面稳定再比较固定特征，必要点击只能按实际能力记录。普通方向响应与机械限位分别判断；时间戳推进或画面不再变化不单独证明云台已到限位。4.3限位用例保留原连续控制至限位的范围，按每次5秒控制、观察后再决定是否继续，不把一次5秒长按当作到位保证。
- **云台操作录屏与人工判定（4.8）**：按用户确认的上、下、左、右各真实长按5秒，保留动作前、按压过程和松手后的模拟器画面供人工判断。仅本条通过受支持的`任务配置(JSON)`开启`record_video: true`；本轮人工判定可显式关闭`analyze_video`，不改变全局默认。录制的是运行App的Android模拟器屏幕，不以App内录像按钮代替，也不承诺录下宿主桌面或窗口外框。宿主Codex执行方负责在派发前核对录屏能力与单条配置，并核实本任务实际录制启动反馈；不向Flash下发不存在的录屏控制/状态查询动作。宿主在结束后取得本运行真实录屏片段及路径，关联运行ID、方向、时间，缺片段或录像未取得时保留采集缺项。自动操作/录屏完成与人工业务判断分开，不自动判云台或OTA保持通过。4.8原文的真实OTA前后预置位/机位保持范围继续保留；可读基线本次实读，有真实已授权适配升级时才执行，显示已最新或无可用升级时保留已做的方向录屏与OTA未验证范围，不以App重启替代，也不扩大刷机权限。
- **预置位新增与召回**：4.5应直达直播云台/实际“我的机位”入口，不夹入无关的设备设置列表泛查。空列表时按当前实际带“+”的新增图标操作，不把摘要误识别的“图片”字样写成精确文字定位器。实际出现名称字段才输入并核对文本；依据当前表单保存、列表回读，移开视角后召回并比较原场景。仅已打开空列表不代表完成保存/召回；缺少可辨画面时保留对应位置比对未验证。
用户将指定画面截图、操作录屏或日志地址/文件明确作为本条交付目标时，可将画面、动作区间、档位、数量及关联时间写入 Artemis 提示词；操作录屏按上述单条配置启用，提示词本身不能启动宿主录制。本轮9.69的日志地址/文件按上述规则关联实际取得结果。优先使用执行端实际开放的截图能力；只有自动步骤截图时，持续页面可在目标状态稳定后再次观察并记录对应步骤，短时浮层则由执行方争取保留最早有效画面或从已有录像提取，不等整幅直播稳定后才取证；无法捕获时明确缺项，不发明截图工具或预先承诺文件名。宿主将实际资料与运行 ID、对应状态和时间逐一关联后才记为采集完成。通用录屏、归档目录等仍由 Codex 处理；人工业务结论保持待判，不以“采集完成”替代产品通过，也不将未取得的图片、视频或日志记为已留存。
## 已有任务表复盘修订
云存探查样本`d632632d-ec54-4935-8675-0a7a5ed090b2`为6.5，6步约187.142秒；第3步将整页下方面板/拖柄附近误当视频中心，视频外点击后Explorer未找到清晰度，随后进入设置并强停。可见云回看入口未点击，无日期/选时/云录像播放证据；历史只说云服务未核实，没有证据表明已经误判未开通。旧正文已有临时核服务与连续点击要求，本轮强化实际独立探查、正确视频矩形及收尾覆盖；历史生命周期failed、正式业务blocked，中间Checker为inconclusive，保持各自记录，不能据ARTEMIS操作录屏推有云存，不能倒填已查视频。
切档即停样本`20a19b7a-f2e5-469a-9508-eaf18401eb52`为7.4，7步约267.681秒；第5步选高清，第6步主动停止App，第7步报告失败，没有wait、卡回看或拖轴，动作均成功。高清动作返回/末帧至stop仅约9.678秒，未建立本档300秒；3600秒预算未耗尽，未见取消或不可继续故障，等待能力实际存在而未调用。摘要503与辅助服务回退后操作继续，停录WinError 2发生在主动停App后，均不能作为早停原因；本地录像存在且首/中/尾抽样可读，不包含未做的卡回看。正式生命周期failed/业务blocked，最终Checker原答inconclusive，保留差异。按本条选中后计时及完整阶段修订，不加预算、不改模型、不回写旧结果或自动重跑。
休眠样本`e898b8d4-9242-4086-b024-e5e7f78c9b22`为9.32，12步约201.525秒：第6–7步开启并确认休眠，第8步BACK只到设备设置外层，第9步再次进入休眠，第10步关闭开关并出现“设置成功”，第11步直接强停App，第12步主动结束。已有关闭尝试，缺的是休眠开启后的直播观察及关闭后的直播恢复验证；不能说完全没执行关闭，也不能将开关灰色视为真实推流恢复。原正文已有推流与恢复要求，执行未落实页面和顺序；第5步索引错误在第6步已纠正，不是持续阻塞，无总超时终止证据。生命周期completed、正式业务inconclusive及原配置保持，按 [9.32休眠直播与唤醒恢复](#休眠直播检查与唤醒恢复932) 补串行必做阶段，不回写历史为通过、不自动重跑。
自动维护日期样本 `2e1d02c2-6134-416e-b45a-92563b85f3c1` 为9.31，原执行正文已明确设置页最上方设备图标与型号五击。实际14步中在设置列表5次向下查看、4次回顶，未点击顶部设备图标、未读取真实型号或执行五击，也未进入设备自动维护配置；回顶后仍因当前设置页未见型号即强停并报告失败。主列表开发者分组、自定义编码参数及固件升级版本不补证已进入模式。会话约215.761秒，属于主动受阻收尾，历史执行failed、业务blocked保留。按用户新确认的 [9.31最近维护日期](#设备自动维护最近日期检查931) 修订路径落实和日期存在性判据，原周期、重启、日志与跨日条件仍未验证，不回写历史为已读取日期、已维护或已通过。
卡回放选时样本 `5250cbe5-e63f-488d-b315-204aad62fc0f` 为7.4，原正文已写逐档各5分钟及条件式“需选时先试拖”。实际使用早图与click_sequence打开清晰度菜单，高清初始选中后切标清并等待300秒，但高清未补足5分钟、超高清受30秒体验限制未选择；进入卡回看后无拖动、选日或选时回读，第13步推理“不拖动到无证据的区间”即强停。原图“今”已选，指针停约12:56，时间轴灰色段可见，未定位本次约13:08切换与随后播放时段；右侧推广卡不能证明卡时间轴无效，也不能据默认旧帧认定无TF卡或本次录像不存在。历史执行failed、业务blocked保留；约644.4秒、未达3600秒总预算。按 [7.4实际选时与视频采集](#卡回放本次切换点定位与操作视频74) 将选时由条件句改为必做、区分拖动无效与目标无数据，并按用户补充把音频判定交人工；不以新口径倒填旧运行已拖轴或已通过。
云回看逐档样本 `f0044b0a-4439-434a-9d88-a092ad232a90` 为6.5，实际初始正文已明确逐档各5分钟再查对应云录像。共6步：启动、进直播、误点相机、进云回看、强停、报告completed；无清晰度选项点击或等待调用。第3步归一化(520,550)换算像素(561,1056)落在相机工具栏，早图有截图预览，本次已有early_post_observation，不能再归因为早图完全缺失；误点后未纠正就跳过直播阶段。会话159.397秒，设备卡点击至云回看最多69.223秒，未触及3600秒总预算；任何一档均不足300秒。回看“今”实际选中，画面为2026-10-19 12:53:11，早于任务13:01:33开始；旧事件不对应本次。其他服务卡“未开通”不证明云存未开通。历史执行completed、业务blocked保留，PASS目录名不代表通过；原录像实际存在并完整解码，156.81秒、无音轨，不能由停止录屏报错推定无录像。按 [6.5阶段与对应新录像](#直播逐档五分钟与对应云录像65) 修订，不固化样本坐标、不回写旧结果。
直播浮层再次失败样本 `b00d7a56-0a19-4091-a81f-b69923d2385b`（3.3）与 `12f95604-fdcb-426d-a827-af4d4704081c`（3.6）均已逐字核对使用V7正文；“未出现控件”的旧报告被实际早帧及录屏否定。两者落点在视频内，浮层约5秒后隐藏，执行器继续多轮稳态观测仅返回晚帧，首次入口因此始终未知，随后没有执行 `click_sequence`；3.6另尝试无依据的同点双击。按 [首次发现、早末帧和本次证据](transient-controls.md) 修订，不能再只追加“快速点击”，也不能归为旧稿未导入、产品没弹出或任务总超时。3.3实际高清持续10分钟、3.6小窗/全屏往返及质量仍缺项，原 `failed/blocked` 保留。代码层保留早帧供决策、技能流程更新与新设备复测是三个独立状态；不以文件校验或单元测试通过倒填业务跑通。
缩略图刷新样本 `0cdd62d4-df03-4aef-9c90-7df979250cef` 是3.2“设备缩略图展示”。第3步已进入真实缩略图模式，页首欢迎区和标题完整；第4–5步向下浏览至长虹第三张目标卡片，旧图时间16:04:49。全链仅第6步一次向下手势，其后只是较上方首卡重新出现，欢迎区仍未显示、标题被固定栏裁切；没有确认到顶后再次下拉，也无刷新触发的有效证据，第7步随即向下浏览回目标。原“找到目标并下拉”说明漏了顶部前提，执行又把普通回滚称为刷新，终检沿用动作自述与旧图不变判失败，三处须分别修正。第8–9步实际进入同设备直播，记录16:09:42及16:10:00；第10步返回后新图时间16:10:16且内容改变，返回更新已观察到，不能写成整条没有更新；新图与较早直播帧构图不同不等于更新失败，也不证明精确最后一帧匹配。历史执行 `completed`、业务 `failed` 原值保留，复核另记“手动下拉刷新触发未验证；退出直播后目标缩略图更新已观察到，原刷新失败依据不足”，按 [本条两段操作与独立验收](#缩略图顶部下拉与直播返回更新32) 修订，不倒填手动分支已完成或整条通过。日志实际FlashRunner与摘要Pro标签差异保留。第11步停止App有回执及桌面反馈，第12步报告结束，主/前缀子进程未独立核验的范围仍保留。
自定义桌面样本 `1c060f98-8e88-4d21-88fa-840144f2ef41` 是23.28“更换已应用自定义桌面”。第12–14步从相机胶卷选图并提交，返回自定义列表后新增可辨室内照片、计数由1/6变2/6，第19步再次返回仍见该新图，按用户本次确认的口径已有App上传执行完成证据。第15/20步点击图片仍在列表，未见预览、应用或“使用中”，只支持选择/应用效果待核，不足以认定B应用失败；第17–18步实际选择家庭场景系统主题C且App显示“使用中”，不能由动作自称“月球”或该标记推出实体显示及无重启/离线。原实体A也未核实。旧删除操作后3/6变1/6与动作自称删一张的关系未充分核对，不据此编造精确删除对象或恢复情况，也不将旧选用的用户既有照片当作后续素材准备范例。历史执行 `failed`、业务 `failed`、`execution_failed` 原值保留，复核另记“按用户新口径上传执行完成，桌面结果人工待核”；采用 [本条上传与人工核对范围](#自定义图片上传与人工核对)，不将原B/C效果缺证继续作为新上传任务失败依据，不倒填原完整A/B/C通过。第21步停止App有回执及桌面反馈，第22步报告结束；无恢复初始主题或删除新图记录，主/前缀子进程未独立核验的范围保留。
七天声音告警样本 `1ff4c406-14a2-40b6-968f-75fb5e4bf3c2` 是1.14“7天挂测设备异响检查”。第6步先查看10月15日01:57:58一条“较大声响”，视频停00:00、时长00:26，未见有效播放核听或声源确认；第7–10步才进入设置，确认声音侦测蓝色开启、灵敏度实际位于“高”，未修改。没有逐日选查最近7天或取得完整含夜间观察。历史执行 `completed`、业务 `failed` 原值保留；原失败将一条声音告警直接视为设备异响，复核认为该依据不足，设备自身异常声源及原七天“无异响”结果仍待核，不能改写成已证实故障或已通过。原列表A90S-2离线只证明该可见设备的状态，未证它就是已布置的第二监控机，不据此认定实际第二机离线。后续按用户补充的 [先查状态再查七天声音告警](#声音侦测状态与最近七天告警) 修订，不自动开启或移入8.30的两分钟等待，也不以原长期条件缺项直接跳过历史。第11步停止App有回执及桌面反馈，第12步报告完成，主/前缀子进程未独立核验的范围保留；新顺序与七天覆盖不倒填旧记录。
电瓶车算法入口样本 `4e1d97db-c0f5-4772-86f6-2536148e7de6` 是16.124“电瓶车告警功能必须支持的设置项”。第8步仅查看通用移动侦测的开启开关、高灵敏度和区域框，无电瓶车映射；第11步确实进入AI设置，第12–13步向下查看，见“车辆识别”（说明“有车辆出现时视频记录”，状态“去开通”）及后续时光轨迹、出入通知、设备巡检，未取得目标电瓶车算法/开关。第13步仍有新条目，第14步即返回，无可靠续滑不变或明确底端证据，不能将“已查AI设置”写成已穷尽。第15–16步只读AI周界和区域入侵，未开启或修改；按用户随后确认，不再将这些功能作为电瓶车算法候选。历史执行 `completed`、业务 `inconclusive` 保留，未把通用控件判成四项支持通过；本次沿 [电瓶车独立算法与四项支持](#第16部分云化ai算法范围与入口) 修订，保留实际已查AI列表范围，不倒填目标已找到、确定不支持、必须付费或已完成四项核验。第17步停止App有回执及桌面反馈，第18步报告结束，主/前缀子进程未独立核验的范围保留。通用控件映射不足与未找到目标算法分别记录，不引入车辆16.75的实车区外负向要求。
车辆算法入口样本 `31ac0cd2-2193-42f2-98dd-c26bb01e9796` 是16.75“设备功能”，归属车辆识别/AI车辆识别功能。第5步进入设备设置，第6–7步向下查看但未证明到底；第8步只读“AI周界”，区域入侵和越界侦测均未开启，第10步只读“移动侦测”的开启状态、高灵敏度与默认全画面框，未修改这些开关或区域。没有进入AI设置、确认目标AI车辆算法/开关，也没有真实区外车辆刺激及对应识别/记录结果。旧执行本已说明候选不等同并保留受阻，不能描述成已经开启AI周界、执行了车辆算法或误判通过；本次按用户确认进一步排除这条候选路径，采用 [AI车辆识别独立入口及未见开关分支](#第16部分云化ai算法范围与入口)。历史执行 `failed`、业务 `blocked`、`execution_failed` 保留，不属于超时或已证实的算法缺陷，也不倒填为设备确定不支持。第11步停止App有回执和桌面反馈，第12步报告失败，主/前缀子进程未独立核验的范围保留；原真实区外负向条件不因入口纠偏被删除或扩为区内正向测试。
人脸AI启用缺项样本 `2bca40cb-1d1e-4644-a349-169e6e97dda8` 是16.10“设备倒装时旋转视频源，上报人脸图片需翻转处理”。历史未进入AI设置，也未读取、开启或保存回读云化人脸算法；第7步只成功开启“画面与声音 → 翻转视频源”，第17步关闭恢复，两次均有开关变化及“设置成功”。第11/13步查看的是01:57:58“较大声响”旧事件及其灰白模糊图片/录像，早于本轮翻转启用，既不是已确认的人脸算法上报，也不能补证本次修改态效果；真实实体倒装亦未证实。第18步停止App有回执及桌面反馈，主/前缀子进程未独立核验。历史执行 `completed`、业务 `inconclusive` 保留；本次按用户补充的 [16.10人脸AI开启分支](#第16部分云化ai算法范围与入口) 增加启用和回读，再取得匹配的人脸图/云录像，不把翻转开关或旧事件倒填为人脸AI已开启、云化效果通过或设备不支持。
云化算法范围样本 `3664b280-49da-43eb-9bbb-4bcd77afe859` 是16.2“人脸抓拍实际场景算法效果准确率测试”。第5步进入设备设置，第6–7步向下查看，第8步打开主列表“功能设置”中的“人脸侦测”（标有“云存储专属”），子页仅见灰色关闭开关；未开启该开关，也未进入“AI设置”或取得对应云化算法信息，第9步停止App，第10步报告结束。按用户随后确认，此处属于端侧人脸侦测，不能作为本条云化算法存在或状态的证据；原查找范围也未证明AI设置已查完，不能直接认定设备不支持云化算法。历史执行 `completed`、业务 `inconclusive` 保留，原缺少适用口径、真实样本及指标的情况仍成立；复核补充云化入口漏查与算法对象不符，后续优先按 [云化AI入口与能力边界](#第16部分云化ai算法范围与入口) 核对，不因室外条件或样本缺项跳过可独立查看的AI设置。停止App有回执及桌面反馈，主/前缀子进程未独立核验的范围保留；不改写旧记录为已开启端侧、已验证云化、确定不支持或算法效果失败。
版本格式样本 `abeb226f-41a8-43ef-bcbc-df945873d3a2` 是13.13“固件包版本校验”，原仅要求查看版本并核三段纯数字、每段最多5位。第7步后设置列表可见“固件升级 1.0.01”，第8步点击该入口；第9步动作前截图已显示“固件升级”“当前已是最新版本”“当前版本 1.0.01”，随后停止App。历史执行 `completed`、业务 `failed`，失败理由是页面未出现字面“固件包版本”；用户随后明确该页版本就是本条目标字段，确认操作正确。结合原截图与该字段对应关系，本次复核应更正为取值路径正确、版本格式通过，`1.0.01`三段位数为1/1/2，不能继续沿用原字面标签误判；保留原结果与用户确认后的复核结论及依据分别追溯，不改写旧DB/trace或冒称已重跑。停止App动作与桌面反馈已有记录，主/前缀子进程未独立核验的范围仍保留，不影响已取得的格式证据。后续按 [本条字段与格式规则](#用户确认路径与人工判定采集) 修订，不追加版本相等或真实升级要求。
间歇恢复后总超时样本 `1725bc2a-caa3-492b-bb1d-67a4125ce04c` 的持久编号是12.3，名称“静态码率压降效果测试”；原始执行为FlashRunner，摘要标Pro。只完成启动、关弹窗、进入设备直播和等待10秒四步；Turn3一次、Turn4三次、Turn5一次，共5次模型请求timeout及10秒重试间隔，耗尽继承批次的1800秒总预算。第3步点击描述达56,791字符且包含重复自我叙述，点击仍成功；其后上下文增大，不能把异常文本与后续超时的先后关系当作唯一根因。间歇动作恢复不补回已用时间，唯一明确业务等待只是10秒，不同于12.6样本的30分钟等待预算不足。未进入设置、读取能力或智能编码状态、开启回读、测量真实静态输出，也未执行强停App；历史 `failed / blocked / task_timeout`、业务与收尾缺项均保留。录屏持久状态ready且无错误不支持归因为录屏故障，旧控制文件running不能覆盖最终失败终态。按下述累计异常与重试预算规则、[本条效果范围](#用户确认路径与人工判定采集) 修订，不倒填路径已走通、静态压降失败或通过。
静态压降样本 `156895f6-c3fe-4e5b-acd5-e3bdeb3003bc` 是12.29“静态码率压降开关（暨‘智能编码’开关）”。实际15步中，第5–7步仅查到仍在推进的功能设置，第8–9步查看“AI设置”，第11–12步反向回滚，第13步进入“画面与声音”，随后停止App并报告失败；未进入“自定义编码参数”、未读智能编码初态、能力/配置项上报或实测两态输出。后续沿用户确认的 [智能编码入口与本条边界](#用户确认路径与人工判定采集) 修订，不能因候选页未见控件认定设备不支持。历史执行 `failed`、业务 `blocked`、`execution_failed` 保留；实际FlashRunner与摘要Pro分别记录。第2步点击描述异常冗长，但点击成功且后续继续，不据此认定为本次入口未定位根因；收尾后录屏报错也不解释前序漏查。强停App回执成功与主/子进程未独立核验分别保留，新路径不倒填旧开关或压降效果通过。
十二小时历史样本 `fb5bb019-6307-45d6-949d-3958de56a565` 的原任务是12.28“设备运行稳定性测试”，要求动态高码率直存、SD卡及实际适用负载下至少12小时无重启/掉线。实际19步主要检查/调整移动侦测、声音侦测及移动追踪，第17步只看存储卡容量16.69G/28.82G，第18步强停、第19步主动报告失败；未进入云回看、卡回放或检查任何12小时时间轴。后续按用户新增的 [最近十二小时检查](#最近十二小时云存卡存空洞检查) 独立查看已有历史，不以新挂测/负载缺项阻断，也不把容量页当卡存录像或改开关当长期负载证据。历史执行 `failed`、业务 `blocked`、`execution_failed` 保留，实际FlashRunner与摘要Pro分别记录；本次不是任务总超时。收尾后屏幕录像停止报错与前序未查时间轴分开，旧运行不能倒填为按新颜色口径已发现/排除空洞或稳定性通过。
稳定性历史样本 `ccd4adcb-fe82-4050-9c8a-319395d333e7` 的原任务是12.24，要求7×24小时挂机、每天10事件、事件无丢失且能正常播放。实际8步只查看告警页“暂无告警”、当前云回看约00:00–00:50的一屏及“一天快放”播放，未切卡存、未逐日选最近7天、未拖动覆盖录制时段或记录空洞。第6步摘要称空白时间轴，未经本轮颜色口径与应录制条件复核，不能倒填成已发现空洞；视频画面灰白也不证明时间轴纯白缺段。后续按 [最近七天历史检查](#最近七天云存卡存空洞检查) 优先查看两种存储既有记录，原长稳和每日事件断言分别保留，不以缺新7天挂测阻断历史检查。历史执行 `failed`、业务 `blocked`、`execution_failed` 保留；日志存在一次模型请求超时重试，但本次最终主动报告失败，不是任务总超时。实际 FlashRunner 与摘要 Pro 分别记录，OSD年份识别冲突不作为最近七天日期依据；强停动作成功与进程列表未独立核验分别保留，收尾后的录屏报错不冒充前序未检查的原因。
码率实测样本 `eeafe931-ae71-41ef-91a4-bfed4d4a547e` 的原任务是12.14。实际10步中，第5步仅查看“画面与声音”，未继续滑动设置列表、未进入“自定义编码参数”；第8步动作描述称点直播画面，实际视觉摘要指出落点在底部面板上沿灰色拖柄。第9步停止 App，第10步报告失败；未开启/核验智能编码、选择 H265/H264、切换超清/高清，也未录制任一完整5分钟素材或输出平均码率。后续按用户补充的 [四组合录制与实测判定](#编码组合录制与码率判定1214) 修订，不能从错点后未见控件或候选页未见参数推断设备不支持。历史执行 `failed`、业务结果 `blocked`、`execution_failed` 保留；原始 FlashRunner 与摘要 Pro 分别记录。会话结束后的自动化屏幕录制停止报错是独立取证问题，不能作为此前查找结束的原因或摄像头码率来源；停止 App 回执成功不等于已单独检查主进程及子进程。用户确认路径不倒填成旧运行证据，无新素材则不虚构四段视频或实测数值。
用户要求“指定批次执行完成的用例 + 本次优化用例”时，先精确核对批次名、创建时点和稳定 ID，以该批逐条最终执行状态 `completed` 建立集合，保留业务结果原值；与优化用例的来源行映射后取并集。跨批次映射须核对完整序位、编号、名称及所属项目，不依赖编号唯一。用户新标记的“暂不适用、测试不执行”优先于历史完成状态，从派发集合排除；全量记录可保存在“暂不适用”等非“任务”页。当前导入器不支持 `enabled`/`skip` 字段，不能只在前置列写“不执行”却仍保留为“任务”行，也不伪造配置字段。历史 completed 只表示曾执行结束，筛选版如实说明其来源和仍需落实的条件，不承诺将来必定完成或业务通过。
复盘异常超时时，分别核对模型请求超时/重试、任务总时限、暂停期限、设备观测/动作超时及业务等待；以原始配置、日志时间轴、动作耗时及终态结果定位。模型把大量重复自我催促文字写进工具参数时，记录为执行器/模型响应异常，不归为产品或设备动作失败；提示词只写本条目标、已确认入口、必要反馈和有限恢复，动作描述只含当前控件，不继续加入无关泛查。此类精简只降低任务歧义，不能宣称修复了模型服务；诊断和后续编排留给执行方，不静默切换模型、修改全局配置或延长时限。摘要所报 Flash/Pro 与实际配置/日志不符时分别保存，不能用错误摘要覆盖原始执行方式。
执行方发现异常参数或连续模型超时且 UI 步骤不增长时，先调用 `mobile_diagnose`，同时保留最后一次成功动作、当前重试轮次及真实已过时间；诊断当前正常不反证历史模型请求正常，HTTP 200 也不能单独证明流式响应已完整结束。按已确认的请求/重试与无进展预算提早处理受阻任务，需结束运行时使用已有授权的任务管理能力，不等任务总时限耗尽，也不把模型重试变成业务用例自动重提。已获准的恢复或新运行先重新观察当前页面，以最后确认阶段为参照，不能重放已成功动作或复用旧坐标。任务超时或取消后另核约定的 App 收尾及证据文件：终止 runner、释放设备、停止 UIAutomator2 均不证明已强制停止 App；按既有授权和设备空闲条件补做，未补则保留收尾缺项。录屏停止报错不等于文件必定不存在；取得真实文件后检查可读性与覆盖区间，不将编译器的空步骤摘要当作整条没有原始证据。这些属于执行方交接，不拼入业务提示词，也不由本 skill 实际执行。
模型异常间歇恢复时，执行方仍应记录跨回合累计请求/重试耗时、超时次数、异常参数及原目标实际进度；一次成功点击或短等待只证明该动作完成，不能抹去已消耗预算或直接认定链路恢复稳定，也不能误把其中真实合法等待的时长记成模型耗时。联合核对单次请求时限、重试次数/间隔与整条剩余预算，为必要业务、诊断及收尾留余量；若采用300秒单次请求、最多重试5次及每次10秒间隔，一个逻辑请求最坏已达 `6×300+5×10=1850秒`，不能认为1800秒总时限足以等完该请求再做业务。该计算是策略上界示例，历史值以当次配置/日志为准，不自动调参或延长全局时限。执行端“等待模型”提示、HTTP200、无工具回退或动作失败兜底，不证明正在内部重试的完整请求已结束；是否能提前中断以实际网关和宿主能力为准，技能文字不能代替运行层预算感知与参数校验。动作描述含伪工具调用、重复自我催促或异常长段，即使动作成功也保留模型输出异常；诊断只引用控件、长度、简短摘要和原始证据路径，不把长重复全文再次注入业务提示词或恢复指令，不改写旧trace来隐藏异常。
复盘“直播点击后没有控件”时，按 [瞬态取证与诊断](transient-controls.md#执行方的取证与诊断) 核对最早画面与原始录像，不只引用步骤摘要或最终截图。录像证明浮层曾出现时，仅更正该项原因及有证据覆盖的范围，仍保留清晰度切换、播放时长等未完成断言；典型样本及适用限制见 [本次复盘依据](transient-controls.md#已验证样本与适用限制)。
夜视取图样本 `1d2e2c13-8e31-40b7-a295-6654df9a1860` 的第 6 步实际只见“自动”（已选）、“开”“关”；执行未修改模式，因当时提示词强制要求“智能夜视”而中止，未补目标直播图。用户后续确认室内云台可能无智能选项且不得关闭夜视或开启全彩，后续提示词采用上述能力分支；不能倒填该历史任务已完成取图，也不据模式名称差异直接认定产品缺陷。
人形告警视频样本 `5a12a2ec-93e1-43da-9255-0d6f65c752a0` 的第 5–6 步只查看告警列表及“全部告警 / 区域入侵 / 画面变化”分类，未进入设备“设置”，未核查人形侦测是否存在或开启，也未取得可确认的人形事件视频。后续按 [人形侦测与告警判断](#人形侦测与告警判断) 补齐判断顺序；历史执行 `failed`、业务结果 `blocked` 如实保留，既不能改写为设备不支持或告警故障，也不能倒填已完成设置核查与视频质量验证。
声音告警视频样本 `ecfbbe36-241a-432b-b314-5645eba599d8` 的第 4–10 步仅在告警列表查看区域入侵、画面变化、类型及日期，第 10 步选中10月11日并显示“暂无告警”；未进入设备“设置”，未开启或确认声音侦测，也未建立开启后的2分钟等待与对应新告警检查。历史执行 `failed`、业务结果 `blocked` 保留，未找到可确认的哭声视频只覆盖当时所查范围，不证明功能不支持或本次触发失败。后续按用户新增的 [声音侦测开启与两分钟后检查](#声音侦测开启与两分钟后检查) 补齐动作，不倒填历史已开启、已等待或视频质量已验证。
设备型号样本 `097f7d3e-17ff-42ab-9be6-fc0186ab009c` 的原任务是 9.2“验证设备型号”。第 5 步进入设置，第 6 步操作前的首屏截图可见顶部设备图标，但第 6–9 步只向下滚动列表，未点击该图标，未读到实际型号；看到“固件升级 1.0.01”也不能完成型号比较。后续采用用户补充的 [设备信息入口](#用户确认路径与人工判定采集)，先点设置页最上方设备图标再读目标字段。历史执行 `failed`、业务结果 `blocked` 保留，不能倒填已进入该信息页、实际型号与厂商一致或已通过，也不能将漏查入口认定为 App 缺失型号信息。
设置保持样本 `10bbf798-eb8e-42f1-b042-624664a9f54d` 的原任务是 9.21“设置项检查”，要求原七组设置在真实 OTA 前后保持一致。实际第 6–16 步只读取部分升级前配置，未完成全部目标项，也未进入“固件升级”查询可用版本，随后停止 App；无升级完成和升级后读数。后续按用户补充的 [功能设置后查询固件升级](#用户确认路径与人工判定采集) 接续检查，不能把未查询写成没有新版本，也不拿其他 trace 的当前版本读数代替本次升级检查。历史执行 `failed`、业务结果 `blocked` 保留，不倒填已检查版本、已升级或设置保持通过。
水印样本 `bdc2129c-39f1-4dbd-991f-97f1770efb19` 的原任务是 9.65“‘移动爱家’logo 水印开关”。原始日志为 FlashRunner，摘要却标 Pro；仅记录启动 App 和关闭发现设备弹窗两步。第 2 步参数夹带大量重复自我催促文本，但点击实际成功；第 3 轮连续记录 5 次模型请求超时并重试，最终由 1800 秒任务时限终止。执行 `failed`、业务结果 `blocked`，未进入目标设备、水印设置或任何水印结果检查，不能归为点击无效、设备不支持水印或水印缺陷；异常文本与后续超时的先后关系已证实，具体模型服务/传输根因仍待调用层证据。日志另有录屏停止报错，且未见约定的停止 App 动作，分别保留取证与收尾核查，不倒填已完成。
日志样本 `591d3c66-9cfb-41dd-92e2-65434b4f977d` 的原任务是 9.69“设备支持按需上传日志”。第2步进入设置后仅向下查列表，第7步“设备检测”实际打开网络检测页，未点击顶部设备图标进入详情，未调整日志档位，也未取得日志地址或正文。用户随后确认详情中的“设备日志管理”入口及“两次调档、取得日志地址、人工核对”安排，后续采用上述采集分支；历史执行 `failed`、业务结果 `blocked` 保留，不将旧任务泛查当成无日志能力，也不倒填已经调档、取址或等级一致性通过。
码率样本 `14178322-843c-4742-bda3-8144b3aaf9dd` 的原任务是 9.101“码率大小设置”。第7步查看“画面与声音”，第11–12步进入“AI设置”后仅见智能守护等服务，第14步滑到“固件升级/设备检测/网络切换/常见问题/流量播放提醒”区域，随后停止 App；未打开“自定义编码参数”，也未设置码率或核验智能编码互斥。后续按用户补充的 [自定义编码参数入口](#用户确认路径与人工判定采集) 修订，不将原候选页未见控件当作设备不支持。历史执行 `failed`、业务结果 `blocked` 保留，用户确认路径不等于旧 trace 已走通，设置保存、互斥及厂复默认均不倒填通过。
AOV 样本 `151fb9f8-f144-4ecc-99a3-34fbdaed66cb` 的原任务是 9.122“不开启任何告警检测时，在正常环境下挂测（有动态、静态画面）”，预置 AOV 开启，原步骤要求不开直播挂测并查看生成视频流，预期正常播放、无快播。第29步能力集已显示 `support_aov:true`、`aov_on:false`；第30–31步设置页可见“自定义编码参数”，但未打开，随后仍查能力及可视化配置，第38步 AOV 仍为关闭，未设置码率、完成挂测或核验真实视频流。后续按用户补充的 [码率、AOV 与直播检查](#用户确认路径与人工判定采集) 修订，原不开直播挂测与新增直播检查分阶段处理；历史执行 `failed`、业务结果 `blocked` 保留，不将漏查子页认定为没有开启入口，也不倒填码率设置、AOV 开启或播放验证通过。
分辨率样本 `90fcbf99-b040-40a3-aadc-5f89651a0fda` 的原任务是 9.133“分辨率设置（每个清晰度下可上报多个分辨率）”。第5–6步仅检查“画面与声音”，第8–9步查看设置列表部分区域，第9步仍在存储卡、呼叫及功能设置区域；未进入“自定义编码参数”，未读取具体分辨率或支持项，也未完成切换及切换后直播检查。后续按用户补充的 [编码参数分辨率入口](#用户确认路径与人工判定采集) 修订；历史执行 `failed`、业务结果 `failed` 原值保留，但已有证据只支持入口未定位及验证未完成，不证明设备不支持或分辨率切换存在产品缺陷。用户确认路径不等于旧 trace 已走通，不倒填读取、切换或直播音画通过。
智能编码样本 `77d21339-635d-4f13-8bc9-c5a44e3ab21c` 的原任务是 9.137“智能编码开关”。第7步检查“画面与声音”，第10–11步查看主设置列表至“功能设置”，第12步进入“AI设置”后仅见智能服务，未进入“自定义编码参数”；未读到开关原值、未开启或关闭，也未采集有效静态场景的输出码率。后续按用户补充的 [智能编码开关入口](#用户确认路径与人工判定采集) 修订；历史执行 `completed`、业务结果 `blocked` 原值保留，执行结束不等于默认开启、开关生效或压降效果通过。用户确认路径不倒填为旧 trace 已完成，也不从候选页面未见开关推断设备不支持。
AOV 开关样本 `fd3c3a71-42a0-4aa9-b371-5fc5ad314d6a` 的原任务是 9.138“AOV开关”。第5步查看“画面与声音”后返回，第7–9步滑动主设置且每次内容仍向下推进，第9步仅到增值服务、其他及“固件升级/设备检测/网络切换”，第10步便停止 App；结束前截图底端仍为“网络切换”，没有有效续滑后不再推进或可靠边界证据。原说明“已查至设置底部区域”不能证明到底，未进入“自定义编码参数”、未读 AOV 初态、未执行开关。后续按用户确认入口及 [持续查找与末尾确认](#设置页查找与到底确认) 修订；历史执行 `failed`、业务结果 `blocked` 保留，不把供电类型缺项扩大为普通开关不可执行，也不倒填默认状态或两态核验通过。
提前收尾样本 `fe3d8156-d32a-448f-805f-2ca02ffa8671` 的原任务是 9.139 编码参数与 AOV/智能编码互斥。第14步已进入“自定义编码参数”，可见 `gop设置`；第24步在 AOV 开启后只回读码率，第39步在智能编码开启后只回读帧率15，GOP 未读、每次开启后的三项恢复核验均不完整。第40步推理同时写“已完成”及“gop未修改/未核默认”，随后主动停止 App，第41步主动上报 `completed`；会话约473.8秒，未见超时或外部取消，末尾 Checker 才指出覆盖缺口。原始执行为 FlashRunner，摘要标 Pro 的差异分别保留；录屏停止报错发生在会话结束后，不能作为提前停止原因。历史执行 `completed`、业务结果 `failed` 保留；按 [完成检查与收尾](#用例完成检查与收尾) 及 [9.139分阶段核验](#编码参数互斥与完整核验9139) 修订，不能把任意一项参数变更解释为只读一项恢复结果，也不把原已关闭的 AOV 在变更后仍关闭认定为发生自动关闭。既有文案差异与未完成断言分别记录，不删除强制停止约定或以延长时限代替补全检查；本 skill 修改不等于已改变后端 Checker 或重跑旧任务。
直播时延样本 `49bbfe7a-f53f-4b03-8103-093036e2616b` 的原任务是12.6，要求实际播放30分钟后测 `t≤2s`。原始 FlashRunner 完成3个步骤，第4轮明确执行 `wait_for_delay(time_in_ms=1800000)`，等待尚未回返即被任务总时限终止；不是已证实的模型重试或无响应。单条 `timeout_seconds` 未覆盖，继承批次 `54f29c0f-1374-46d9-ae17-0f834bd25e87` 的1800秒预算；等待前已消耗约87.5秒，实际只等约1713.4秒（28分33秒），更无时延测量和收尾余量。按 [长时预算与计时](#长时任务预算与实际计时) 修订本条预算及等待方式；分段等待不能替代预算修正，不缩短30分钟或删除2秒判据。历史执行 `failed`、业务结果 `blocked` 保留，时延、连续播放及 App 收尾未完成均不倒填；摘要 Pro 与原日志 Flash 分别记录，不能沿用水印样本的模型超时根因。
以用户指定或已核实关联的批次为范围，按每个 session/trace ID 对齐原提示词、执行终态、业务结果、原始 Checker 和实际步骤；同编号不能合并。用户给同一运行ID对应多个用例时，先核对该ID实际任务；映射不符则保留原ID与差异，按用户确认的用例原文修订，不将其他任务结论归入本条。保留各来源判定与独立审计，执行 completed、取消和错误包装不能直接转成产品结论。沿用已完成且证据未变的复盘；新证据只更新对应运行和覆盖范围。汇总独立审计时只统计明确保存的审计字段，缺失项单列，不从平台业务结果补入。
修订动作与本条原步骤、预期逐项对应，保持量词与观察端。原动作是“任意一项”时，不把遍历全部选项作为通过前提；同条预期要求三项恢复默认仍须分别核对。原文仅查看支持项时，以可明确映射到目标功能的界面、能力或有效配置分别核实支持，不追加专属独立页面、保存遍历、真人触发或效果场景；共享控件可以分别支持多个要求。视频质量只核本条列出的画面、声音或同步断言，不把相邻事件、人群或电瓶车场景混入，也不将“指定现场人员”写成唯一取证方式。
用户明确要求保留全量既有任务并重新出稿时，可以保留全部条目的原前置、步骤、预期及已确认环境，逐条编写有条件的执行说明，并另列尚缺输入与可执行范围。未具备条件的条目标为审阅稿，不伪装成正式可派发用例，也不以占位值代填业务参数。普通可逆参数、计时起点与已授权素材由执行方按实际能力准备；独立预期、真实物理场景、第二账号、OTA 和跨日周期仍须落实。此分支不替代首次正式转换时的适用性和待补要求，不自动改变原表标记。
真实日期、三小时、24小时或七天任务，在派发前由执行方核对实际时窗、连续观察来源及执行预算；未到时窗不让单条交互任务等待未来数日，也不以多次同日任务冒充多日。原操作和时长保留，App配置与长时效果分别验收。有界业务的总预算不足按上述长时规则在单条配置中修正，不混同模型链路故障。已实际执行的业务等待不能仅因没有新增UI步骤归为异常；连续模型连接错误、未产生动作和请求重试则先由执行方诊断并按已获授权决定后续派发，不能用加长提示词、增大模型超时、反复重提或删除原断言冒充修复。这些编排和故障处理要求写在执行说明文档，不灌入每条 Artemis 任务正文。
## 设备截图分辨率与相册查看
分辨率相关用例可临时离开测试 App，在同一 Android 环境的手机相册/图库中查看图片分辨率；沿用当前用户对该操作的授权与有效应用锁定配置。整理这类提示词时，可要求通过测试 App 的设备截图/抓拍功能保存图片，等待保存完成，再切换到相册，根据本次截图的时间、文件名或画面内容找到对应原图，打开图片详情读取像素宽×高。截图入口、保存位置与相册详情入口须按实际界面观察，不预设固定菜单、坐标或相册名称。不能仅凭“最新一张”认定是本次图片。
以该截图原图的像素宽×高作为实际值，与原用例或用户已确认的预期尺寸比较。若用例要求核验视频流分辨率，须先由原文或用户资料确认截图尺寸与该断言的对应关系；图片尺寸本身不补足缺失的判据。查看和核验完成、达到本条退出条件后，移动爱家按统一收尾要求强制停止 `com.cmri.universalapp` 并由执行方核对主/前缀子进程；其他 App 或用户当前明确另有安排时按其约定收尾。
Codex 准备任务配置时须核对有效的 `locked_app_package` 及其继承值，确保该任务可以切换到相册；若当前配置把操作限制在测试 App，按服务支持的方式在该任务范围取消应用锁定，不修改其他任务或全局默认。设备截图和相册查看是这类用例的具体操作，不将给 Codex 的通用截图、录屏及证据归档段落附到提示词中。
plugins/codex/plugins/caveman/THIRD_PARTY_SOURCE.json
+2 -2
View File
@@ -2,8 +2,8 @@
"sourceId": "caveman", "sourceId": "caveman",
"repo": "https://github.com/JuliusBrussee/caveman.git", "repo": "https://github.com/JuliusBrussee/caveman.git",
"ref": "main", "ref": "main",
"commit": "81958ad82f2e2da4417778f81f8a3c838d81b798", "commit": "bad48a0e1df55e05e3f52249afa35ecc1909ee76",
"adapter": "codex-plugin", "adapter": "codex-plugin",
"sourcePath": "plugins/caveman", "sourcePath": "plugins/caveman",
"syncedAt": "2026-10-17T16:00:00Z" "syncedAt": "2026-10-21T06:48:34Z"
} }
plugins/codex/plugins/dingtalk-workspace/.codex-plugin/plugin.json
+1 -1
View File
@@ -1,6 +1,6 @@
{ {
"name": "dingtalk-workspace", "name": "dingtalk-workspace",
"version": "1.0.64", "version": "1.0.65",
"description": "通过 dws CLI 操作钉钉消息、文档、表格、日历、待办和知识库的官方 Skill 集合。需要另行安装匹配版本的 dws、登录并取得企业授权；辅助脚本需要 Python 3。", "description": "通过 dws CLI 操作钉钉消息、文档、表格、日历、待办和知识库的官方 Skill 集合。需要另行安装匹配版本的 dws、登录并取得企业授权；辅助脚本需要 Python 3。",
"author": { "author": {
"name": "DingTalk", "name": "DingTalk",
plugins/codex/plugins/dingtalk-workspace/THIRD_PARTY_SOURCE.json
+3 -3
View File
@@ -1,9 +1,9 @@
{ {
"sourceId": "dingtalk-workspace", "sourceId": "dingtalk-workspace",
"repo": "https://github.com/DingTalk-Real-AI/dingtalk-workspace-cli.git", "repo": "https://github.com/DingTalk-Real-AI/dingtalk-workspace-cli.git",
"ref": "v1.0.64", "ref": "v1.0.65",
"commit": "e2c0cdf97e016ee76687d9c26986c23a26a84738", "commit": "92c4f8c355c749ec470c68f998d862a00d7d1709",
"adapter": "skill-collection", "adapter": "skill-collection",
"sourcePath": "skills/multi", "sourcePath": "skills/multi",
"syncedAt": "2026-10-14T16:00:00Z" "syncedAt": "2026-10-21T06:48:34Z"
} }
plugins/codex/plugins/dingtalk-workspace/skills/dingtalk-aitable/SKILL.md
+1 -1
View File
@@ -236,7 +236,7 @@ Golden/次级直达覆盖时不读 Reference；否则按最终专有能力读取
| 自动化工作流 | [workflow](references/aitable/aitable-workflow.md) | | 自动化工作流 | [workflow](references/aitable/aitable-workflow.md) |
| 普通角色或高级权限 | [advperm](references/aitable/aitable-advperm.md) | | 普通角色或高级权限 | [advperm](references/aitable/aitable-advperm.md) |
| 数据源接入、同步管理、sourceConfig 构造或审批数据同步 | [datasource](references/aitable/aitable-datasource.md) | | 数据源接入、同步管理、sourceConfig 构造或审批数据同步 | [datasource](references/aitable/aitable-datasource.md) |
| 访问密钥创建、查询或撤销 | [api-key](references/aitable/aitable-api-key.md) | | Supabase 访问密钥创建、查询或撤销 | [supabase api-key](references/aitable/aitable-api-key.md) |
| SQL、PostgreSQL、SELECT 或同 Base 多表 JOIN | [psql](references/aitable/aitable-psql.md) | | SQL、PostgreSQL、SELECT 或同 Base 多表 JOIN | [psql](references/aitable/aitable-psql.md) |
| 产品边界不明确 | [intent-guide](references/intent-guide.md) | | 产品边界不明确 | [intent-guide](references/intent-guide.md) |
| 只有上述 Reference 仍无法定位的低频原子能力 | [aitable.md](references/aitable.md) 的对应章节 | | 只有上述 Reference 仍无法定位的低频原子能力 | [aitable.md](references/aitable.md) 的对应章节 |
plugins/codex/plugins/dingtalk-workspace/skills/dingtalk-aitable/references/aitable/aitable-api-key.md
+6 -4
View File
@@ -1,14 +1,16 @@
# SQL Sheet API Key 管理 # SQL Sheet API Key 管理
`dws aitable api-key ...` 管理指定 Base 的 SQL Sheet 访问凭据，使用当前登录用户的身份。 `dws aitable supabase api-key ...` 管理指定 Base 的 SQL Sheet 访问凭据，使用当前登录用户的身份。此处 Supabase 指 AI 表格提供的兼容接口。
旧路径 `dws aitable api-key ...` 继续兼容，参数和返回结果相同；新接入使用上述路径。
## 命令 ## 命令
| 意图 | 命令 | 关键参数 | | 意图 | 命令 | 关键参数 |
|---|---|---| |---|---|---|
| 创建访问凭据 | `api-key create` | `--base-id`；确认后再追加 `--yes` | | 创建访问凭据 | `supabase api-key create` | `--base-id`；确认后再追加 `--yes` |
| 查询有效凭据 | `api-key list` | `--base-id` | | 查询有效凭据 | `supabase api-key list` | `--base-id` |
| 撤销指定凭据 | `api-key revoke` | `--base-id --key-id`；确认后再追加 `--yes` | | 撤销指定凭据 | `supabase api-key revoke` | `--base-id --key-id`；确认后再追加 `--yes` |
三个命令均要求 Base 的管理权限（MANAGER），每次选择一个 profile。使用 `--dry-run` 预览请求；预览不调用远端服务。 三个命令均要求 Base 的管理权限（MANAGER），每次选择一个 profile。使用 `--dry-run` 预览请求；预览不调用远端服务。
plugins/codex/plugins/dingtalk-workspace/skills/dingtalk-chat/SKILL.md
+5 -5
View File
@@ -1,6 +1,6 @@
--- ---
name: dingtalk-chat name: dingtalk-chat
description: 钉钉群聊与消息。Use when 收发/搜索消息、建群、群治理、Bot/Webhook、文件，或仅限 IM 的消息谓词筛选。跨源主题/行为轨迹走 dingtalk-aisearch；DING/班级群走 dingtalk-misc；邮件走 dingtalk-mail。 description: 钉钉群聊与消息。Use when 收发/搜索消息、建群、群治理、Bot/Webhook、文件、AI/A2UI 卡片流式，或仅限 IM 的消息谓词筛选。跨源主题/行为轨迹走 dingtalk-aisearch；DING/班级群走 dingtalk-misc；邮件走 dingtalk-mail。
metadata: metadata:
cli_version: ">=0.2.14" cli_version: ">=0.2.14"
category: product category: product
@@ -51,7 +51,7 @@ metadata:
| 已知消息 ID 批量取详情 | `dws chat +messages-mget` | 看 leaf Schema；保留会话上下文 | | 已知消息 ID 批量取详情 | `dws chat +messages-mget` | 看 leaf Schema；保留会话上下文 |
| <!-- dws-intent: chat.send.dm -->按姓名发文本/Markdown | `dws chat +dm --to <姓名> --content <内容>` | 唯一解析；多候选停止 | | <!-- dws-intent: chat.send.dm -->按姓名发文本/Markdown | `dws chat +dm --to <姓名> --content <内容>` | 唯一解析；多候选停止 |
| <!-- dws-intent: chat.send.group -->按群名/ID 发文本/Markdown | `dws chat +send-to-group --group <群名或ID> --content <内容>` | 多候选停止 | | <!-- dws-intent: chat.send.group -->按群名/ID 发文本/Markdown | `dws chat +send-to-group --group <群名或ID> --content <内容>` | 多候选停止 |
| <!-- dws-intent: chat.send.advanced -->文件/Bot/Webhook/复杂 @ | `dws chat +messages-send` | Bot 多群检查逐项 ledger | | <!-- dws-intent: chat.send.advanced -->图文/文件/Bot/Webhook/复杂 @ | `dws chat +messages-send` | 本地图文先读[资源](references/chat/message-media.md)；Bot 多群检查逐项 ledger |
| 全部会话 | `dws chat +conversation-list --page-all` | 含群聊/单聊，非正文 | | 全部会话 | `dws chat +conversation-list --page-all` | 含群聊/单聊，非正文 |
| 查加入/管理的群 | `+my-groups --page-all` / `+chat-list-mine` | 后者无 `--page-all`；flag 不跨 leaf | | 查加入/管理的群 | `+my-groups --page-all` / `+chat-list-mine` | 后者无 `--page-all`；flag 不跨 leaf |
| 搜群或查看全部成员 | `+chat-search --query <词>` / `+chat-members-list --group <群名或ID>` | 多候选停止；检查 buckets/完整性 | | 搜群或查看全部成员 | `+chat-search --query <词>` / `+chat-members-list --group <群名或ID>` | 多候选停止；检查 buckets/完整性 |
@@ -73,11 +73,11 @@ metadata:
## 关键结果语义 ## 关键结果语义
- 查询保留范围、数量、完整性、停止原因、失败/下载 ledger；不完整不得称成功。消息仅 `--page-all` 翻页，达预算返回有界 partial。 - 查询保留范围、数量、完整性、停止原因、失败/下载 ledger；不完整不得称成功。消息仅 `--page-all` 翻页，达预算返回有界 partial。
- 本地图片仅已有 `mediaId` 才发内联 image，否则发 file；只上传不发送用 `conversation-file upload`。
- 子消息用自身 messageId；缺 CID 才继承父 conversationId。写操作沿真实结果传 ID。 - 子消息用自身 messageId；缺 CID 才继承父 conversationId。写操作沿真实结果传 ID。
## 写生命周期 ## 写生命周期
- 钉钉回复任务：接入方默认先发 A2UI 占位、执行中更新；主动发送默认完整投递。按[占位与流式](references/card/a2ui.md)执行。
- 多步骤写先校验目标、限制、内容、确认，再沿稳定 ID 串行执行并验证；不截断或换目标。临时资源保留 ID/阶段，失败仅做已授权清理。 - 多步骤写先校验目标、限制、内容、确认，再沿稳定 ID 串行执行并验证；不截断或换目标。临时资源保留 ID/阶段，失败仅做已授权清理。
## 上下文预算 ## 上下文预算
@@ -94,11 +94,11 @@ metadata:
| 消息 | [查询](references/chat/message-query.md) / [动作](references/chat/message-actions.md) / [资源](references/chat/message-media.md) | | 消息 | [查询](references/chat/message-query.md) / [动作](references/chat/message-actions.md) / [资源](references/chat/message-media.md) |
| 群 | [读取](references/chat/group-discovery.md) / [治理](references/chat/group-admin.md) | | 群 | [读取](references/chat/group-discovery.md) / [治理](references/chat/group-admin.md) |
| 会话/Bot | [会话](references/chat/chat-conversation.md) / [Bot](references/chat/chat-bot.md) | | 会话/Bot | [会话](references/chat/chat-conversation.md) / [Bot](references/chat/chat-bot.md) |
| 组合/话题/表情/卡片 | [组合](references/01-messaging.md) / [话题](references/chat/thread.md) / [表情](references/chat-emoji-list.md) / [卡片/A2UI](references/card/schema.md) | | 组合/话题/表情/卡片 | [组合](references/01-messaging.md) / [话题](references/chat/thread.md) / [表情](references/chat-emoji-list.md) / [卡片/A2UI流式](references/card/schema.md) |
| 结果/其他原子能力 | [contracts](references/contracts.md) / [chat](references/chat.md) | | 结果/其他原子能力 | [contracts](references/contracts.md) / [chat](references/chat.md) |
## 错误最短路径 ## 错误最短路径
1. 零命中/多候选：停止写并消歧，禁默认第一项。 1. 零命中/多候选：停止写并消歧，禁默认第一项。
2. 参数/确认不明查 leaf Schema；Schema 不可用才查已知 leaf Help。`unknown flag` 用同 leaf Help 修正一次；`unknown command` 不查 Help：先用错误的明确 suggestion，再用已加载 Skill/reference 的明确兼容入口；无则报漂移并停，禁全 Catalog。 2. 参数/确认及未知 flag/command：按上方最小 DWS 执行契约处理，禁全 Catalog。
3. 仅 `retryable=true` 按原命令重试一次；API/internal/MCP、写后不一致或无重试性即停，不换 Shortcut/atomic。保留 Trace ID、已完成/待清理项并最终答复；`confirmation_required` 等用户确认，不补 `--yes`。 3. 仅 `retryable=true` 按原命令重试一次；API/internal/MCP、写后不一致或无重试性即停，不换 Shortcut/atomic。保留 Trace ID、已完成/待清理项并最终答复；`confirmation_required` 等用户确认，不补 `--yes`。
plugins/codex/plugins/dingtalk-workspace/skills/dingtalk-chat/references/card/a2ui.md
+45 -7
View File
@@ -1,6 +1,34 @@
# A2UI 展示卡片 # A2UI 展示卡片
使用 `dws chat message send-a2ui-card` 创建卡片，使用 `update-a2ui-card` 更新和完结。`--content` 接受 JSON 字符串数组，每个元素是一条 A2UI 消息。 使用 `dws chat message send-a2ui-card` 创建卡片，使用 `update-a2ui-card` 更新和完结。`--content` 接受 JSON 字符串数组，每个元素是一条 A2UI 消息；传 `-` 时从 stdin 读取同样的内容。
## 回复占位与主动发送
回复用户消息，或处理明确需要交互反馈的事件任务时，默认先发 A2UI 占位卡，再按实际进度更新同一卡片，不要求用户额外指定“流式”。简短回复从占位直接更新为答案，不编造阶段。事件发生本身不构成回复授权。
主动通知、定时日报及完整结果交付默认准备好内容后直接发送，不自动占位或流式；仅在用户明确要求持续展示进度时启用。占位和进度使用可信的当前回复目标与 profile，不根据正文猜测 ID，也不跟随最终交付目标转移。例如私聊交办、报告发到群里时，进度留在私聊，群里默认只收完整报告。
接入 Agent 时，由接入方在确认回复范围、完成去重及目标校验后，通过任务启动钩子调用 `send-a2ui-card`，在调用模型前发送“思考中…”占位，并将公开进度和结果通过 `update-a2ui-card` 更新到同一卡片。钩子和进度采集需接入方实际实现，安装 Skill 不会自动注册。宿主负责卡片时，模型只输出公开进度和结果，不重复创建卡片或发送最终消息；没有宿主钩子时可由模型尽早调用命令，但不能保证模型首次响应前已有占位。不展示内部推理、凭据或工具原始输入输出。
用户只要求最终结果时，省略过程详情；明确不要中间消息或卡片时，还需跳过占位。模型自行发卡时按此选择；宿主发卡时须在钩子前确定回复策略，不能靠模型事后取消首卡。
## 流式执行
以下命令由宿主或模型中的同一方负责执行，不在同一任务中重复接管。已有卡片的交互事件先核实创建记录和更新权限，按业务更新原卡，不默认另建占位卡。
1. 开始执行时调用 `send-a2ui-card`，发送“思考中…”初始布局和运行状态。创建默认 `PROCESSING`；保存服务端返回的真实 `bizId` 和创建命令，后续沿用 `update-a2ui-card`，不能使用请求侧 ID 或 `openTaskId` 替代 `bizId`。
2. 每生成可展示的完整段落或阶段结果，调用 `update-a2ui-card`，使用 `INPUTTING`。每批提交完整有效的 JSON 消息，不发送未闭合 JSON 或逐 token 拼接请求。
3. 使用同一 profile、真实 `bizId` 和 `surfaceId`，已有组件保持原 ID。正文用 `updateDataModel` 提交该绑定路径的累计正文，它会替换路径值，不会追加字符；不要重放无关数据或表单默认值。布局变化用 `updateComponents` 提交完整组件定义，新增组件使用新 ID 并同步维护父组件 `children`，更新批次不再发送 `createSurface`。
4. 同一卡片串行提交，上一批明确成功后再发下一批。更新失败保留原卡，不自动重新创建；请求超时或响应丢失导致结果未知时，暂停后续更新并核实该批是否生效，不能盲目重试。
5. 任务成功完成时，提交非空有效的最终更新并设为 `FINISH`；涉及正文路径时提交累计最终值，无需重发未变内容。已知执行失败、取消或超时，且卡片仍可安全更新时，保留已有结果，用状态文案说明未完成及原因，再以 `FINISH` 结束输出；`FINISH` 不代表业务成功。卡片更新结果未知时停止写入，不强行补发终态。
创建失败或 A2UI 能力不可用时，先确认是否投递：明确未创建、回复目标和权限有效且任务允许文本交付时，可改用最终文本；明确要求 A2UI 时报告限制。超时、响应丢失或缺少真实 `bizId` 均按结果未知处理，停止写入并核实，不自动重建或补发文本。不得通过回退绕过身份、权限或目标校验。宿主是否自动回退须以实际接入实现为准。
这里的流式更新通过多次调用命令实现，Skill 本身不执行钩子或补发。Agent 被强制终止后不能保证自动收尾；无法确认更新结果时应报告已完成的阶段与未验证的状态。
主动完整发送 A2UI 时，创建请求直接携带完整内容，不添加占位或过程阶段；创建成功后仍需沿用真实 `bizId`，提交非空有效的最终更新并设为 `FINISH`。这是协议完结，不需要经历 `INPUTTING` 或分批生成内容。
运行中的面板标题可使用钉钉宿主约定 `[AIGenerating]` 和 `textEffect: shimmer`；仅设置 `PROCESSING`/`INPUTTING` 不会自动给组件添加动画。结束时更新完整面板定义，移除生成标记和文字特效，保持组件 ID，不重设展开状态。
下面以任务进度卡片为例。布局、组件 ID、数据路径和文案可按需求调整，保持引用一致；组件属性可按需查阅[钉钉公开 Catalog](https://dingtalk.com/card/a2ui/catalogs/public/catalog.json)。 下面以任务进度卡片为例。布局、组件 ID、数据路径和文案可按需求调整，保持引用一致；组件属性可按需查阅[钉钉公开 Catalog](https://dingtalk.com/card/a2ui/catalogs/public/catalog.json)。
@@ -11,7 +39,7 @@
```bash ```bash
dws chat message send-a2ui-card \ dws chat message send-a2ui-card \
--open-dingtalk-id '<接收人openDingTalkId>' \ --open-dingtalk-id '<接收人openDingTalkId>' \
--content '["{\"version\":\"v1.0\",\"createSurface\":{\"surfaceId\":\"example-card\",\"catalogId\":\"https://dingtalk.com/card/a2ui/catalogs/public/catalog.json\",\"dataModel\":{\"answer\":{\"displayText\":\"任务已开始。\"},\"status\":\"doing\"}}}","{\"version\":\"v1.0\",\"updateComponents\":{\"surfaceId\":\"example-card\",\"components\":[{\"id\":\"root\",\"component\":\"Column\",\"align\":\"stretch\",\"children\":[\"executionPanel\"]},{\"id\":\"executionPanel\",\"component\":\"CollapsiblePanel\",\"title\":\"正在处理任务\",\"children\":[\"answer\"],\"fallbackMarkdown\":\"任务进度\"},{\"id\":\"answer\",\"component\":\"Markdown\",\"content\":{\"path\":\"/answer/displayText\"}}]}}"]' \ --content '["{\"version\":\"v1.0\",\"createSurface\":{\"surfaceId\":\"example-card\",\"catalogId\":\"https://dingtalk.com/card/a2ui/catalogs/public/catalog.json\",\"dataModel\":{\"answer\":{\"displayText\":\"任务已开始。\"},\"status\":\"doing\"}}}","{\"version\":\"v1.0\",\"updateComponents\":{\"surfaceId\":\"example-card\",\"components\":[{\"id\":\"root\",\"component\":\"Column\",\"align\":\"stretch\",\"children\":[\"executionPanel\"]},{\"id\":\"executionPanel\",\"component\":\"CollapsiblePanel\",\"title\":\"[AIGenerating]思考中…\",\"textEffect\":\"shimmer\",\"children\":[\"answer\"],\"fallbackMarkdown\":\"任务进度\"},{\"id\":\"answer\",\"component\":\"Markdown\",\"content\":{\"path\":\"/answer/displayText\"}}]}}"]' \
-f json -f json
``` ```
@@ -21,23 +49,33 @@ dws chat message send-a2ui-card \
## 更新和完结 ## 更新和完结
更新使用创建时的 `bizId` 和 `surfaceId`。本例修改面板标题和正文： 更新使用创建时的 `bizId` 和 `surfaceId`。本例第一批更新面板标题，写入已生成正文；示例步骤和文案需替换为实际执行结果：
```bash ```bash
dws chat message update-a2ui-card \ dws chat message update-a2ui-card \
--biz-id '<本次发送返回的bizId>' \ --biz-id '<本次发送返回的bizId>' \
--flow-status INPUTTING \ --flow-status INPUTTING \
--content '["{\"version\":\"v1.0\",\"updateComponents\":{\"surfaceId\":\"example-card\",\"components\":[{\"id\":\"executionPanel\",\"component\":\"CollapsiblePanel\",\"title\":\"正在处理第 2 步\",\"children\":[\"answer\"],\"fallbackMarkdown\":\"任务进度\"}]}}","{\"version\":\"v1.0\",\"updateDataModel\":{\"surfaceId\":\"example-card\",\"path\":\"/answer/displayText\",\"value\":\"第 2 步正在执行。\"}}","{\"version\":\"v1.0\",\"updateDataModel\":{\"surfaceId\":\"example-card\",\"path\":\"/status\",\"value\":\"doing\"}}"]' \ --content '["{\"version\":\"v1.0\",\"updateComponents\":{\"surfaceId\":\"example-card\",\"components\":[{\"id\":\"executionPanel\",\"component\":\"CollapsiblePanel\",\"title\":\"[AIGenerating]正在整理分析结果\",\"textEffect\":\"shimmer\",\"children\":[\"answer\"],\"fallbackMarkdown\":\"任务进度\"}]}}","{\"version\":\"v1.0\",\"updateDataModel\":{\"surfaceId\":\"example-card\",\"path\":\"/answer/displayText\",\"value\":\"已完成资料读取。\"}}","{\"version\":\"v1.0\",\"updateDataModel\":{\"surfaceId\":\"example-card\",\"path\":\"/status\",\"value\":\"doing\"}}"]' \
-f json -f json
``` ```
可按任务进度继续更新。任务完成后写入实际结果，并将 `--flow-status` 设为 `FINISH`： 第二批正文增长时，发送包含上一批正文的累计值，保持 `INPUTTING`。本批不修改布局，因此只更新数据：
```bash
dws chat message update-a2ui-card \
--biz-id '<本次发送返回的bizId>' \
--flow-status INPUTTING \
--content '["{\"version\":\"v1.0\",\"updateDataModel\":{\"surfaceId\":\"example-card\",\"path\":\"/answer/displayText\",\"value\":\"已完成资料读取。\\n\\n已整理出分析结果。\"}}"]' \
-f json
```
可按同样方式继续分批更新。任务完成后写入完整实际结果，并将 `--flow-status` 设为 `FINISH`：
```bash ```bash
dws chat message update-a2ui-card \ dws chat message update-a2ui-card \
--biz-id '<本次发送返回的bizId>' \ --biz-id '<本次发送返回的bizId>' \
--flow-status FINISH \ --flow-status FINISH \
--content '["{\"version\":\"v1.0\",\"updateComponents\":{\"surfaceId\":\"example-card\",\"components\":[{\"id\":\"executionPanel\",\"component\":\"CollapsiblePanel\",\"title\":\"处理完成\",\"children\":[\"answer\"],\"fallbackMarkdown\":\"任务进度\"}]}}","{\"version\":\"v1.0\",\"updateDataModel\":{\"surfaceId\":\"example-card\",\"path\":\"/answer/displayText\",\"value\":\"任务已完成。\"}}","{\"version\":\"v1.0\",\"updateDataModel\":{\"surfaceId\":\"example-card\",\"path\":\"/status\",\"value\":\"finished\"}}"]' \ --content '["{\"version\":\"v1.0\",\"updateComponents\":{\"surfaceId\":\"example-card\",\"components\":[{\"id\":\"executionPanel\",\"component\":\"CollapsiblePanel\",\"title\":\"处理完成\",\"children\":[\"answer\"],\"fallbackMarkdown\":\"任务进度\"}]}}","{\"version\":\"v1.0\",\"updateDataModel\":{\"surfaceId\":\"example-card\",\"path\":\"/answer/displayText\",\"value\":\"已完成资料读取。\\n\\n已整理出分析结果。\\n\\n任务已完成。\"}}","{\"version\":\"v1.0\",\"updateDataModel\":{\"surfaceId\":\"example-card\",\"path\":\"/status\",\"value\":\"finished\"}}"]' \
-f json -f json
``` ```
@@ -51,6 +89,6 @@ dws chat message update-a2ui-card \
- `componentId` 对应该 surface 下 `updateComponents.components[].id`，按需要关联的实际组件填写。 - `componentId` 对应该 surface 下 `updateComponents.components[].id`，按需要关联的实际组件填写。
- `type` 表示注解类型，按实际支持的类型和用途选择。 - `type` 表示注解类型，按实际支持的类型和用途选择。
`answer` 和 `artifact` 是本例的取值。更新时也可关联此前已创建的组件。该参数可选，支持 `[]`；省略时创建请求不携带注解字段，更新请求沿用原有的空数组。 本例的 `componentId` 为 `answer`，`type` 为 `artifact`，不要把组件 ID 当作注解类型。更新时也可关联此前已创建的组件。该参数可选，支持 `[]`；省略时创建请求不携带注解字段，更新请求沿用原有的空数组。
发送后核对创建结果和客户端展示，再检查同一 `bizId` 的更新和完结效果。遇到 `a2ui dws catalog validation failed` 时，可对照 Catalog 检查组件属性、JSON 格式、Catalog 地址和 surface 创建顺序。 发送后核对创建结果和客户端展示，再检查同一 `bizId` 的更新和完结效果。遇到 `a2ui dws catalog validation failed` 时，可对照 Catalog 检查组件属性、JSON 格式、Catalog 地址和 surface 创建顺序。
plugins/codex/plugins/dingtalk-workspace/skills/dingtalk-chat/references/card/schema.md
+7 -1
View File
@@ -1,6 +1,12 @@
# 卡片 Schema # 卡片 Schema
文本展示或持续输出文本可参考[创建流式卡片](create.md)；需要组件布局可参考 [A2UI 展示卡片](a2ui.md)。 按内容契约和创建记录选择卡片；A2UI 格式本身不代表需要流式。回复占位与流式、主动完整发送的边界见 [A2UI 指南](a2ui.md)。
- 用户明确要求 A2UI，需要组件布局、数据绑定，或按上述回复流程展示占位和进度时，选用 A2UI；只有正文也可使用 A2UI。发送或更新前先读取上述指南。
- 未指定 A2UI、只需现有文本卡片的正文和流转状态时，沿用[创建流式卡片](create.md)。
- 更新时沿用创建接口：`send-a2ui-card` 对应 `update-a2ui-card`；`send-card` / `+messages-send-card` 对应 `+messages-update-card`。保存真实 `bizId` 及创建命令，不根据本批是否只有文本切换接口；只有 `bizId` 时先核实创建记录。
这两个创建入口均不提供模板 ID 参数。用户指定模板 ID 和模板变量时，先核实可用的模板卡片接口，不把模板 ID 传给 `send-card`，也不根据模板 ID 是否出现判断卡片类型。A2UI 与群聊 @ 的要求同时出现时说明当前参数限制，不自动改成文本卡片。
DWS 公开两类卡片命令契约： DWS 公开两类卡片命令契约：
plugins/codex/plugins/dingtalk-workspace/skills/dingtalk-chat/references/chat/group-admin.md
+4 -1
View File
@@ -14,7 +14,7 @@
和精确 leaf Schema 为准确认对象、动作与影响。 和精确 leaf Schema 为准确认对象、动作与影响。
- 所有自然成员和群主必须先完成唯一解析并按稳定 ID 去重，再开始任何写入；不得边解析边 - 所有自然成员和群主必须先完成唯一解析并按稳定 ID 去重，再开始任何写入；不得边解析边
产生部分副作用。 产生部分副作用。
- 群公告会触达成员；`notice edit` 是整体替换，必须有完整新正文。 - 群公告默认会发群聊卡片；即时公告使用 `--no-card` 可静默发布或更新。`notice edit` 是整体替换，必须有完整新正文。
## 建群与基础资料 ## 建群与基础资料
@@ -113,6 +113,9 @@ dws chat group user-settings set \
定时公告 `--run-at` 使用带时区时间；`notice list --scheduled` 查询待发布公告。分页时沿真实 定时公告 `--run-at` 使用带时区时间；`notice list --scheduled` 查询待发布公告。分页时沿真实
`nextPageCursor` 继续。修改前必须取得完整替换正文，不把增量片段当整篇公告。 `nextPageCursor` 继续。修改前必须取得完整替换正文，不把增量片段当整篇公告。
即时公告的 `create/edit` 可用 `--no-card` 静默更新，用 `--must-read` 开启新人必看；
编辑时用 `--must-read=false` 明确关闭。`--no-card` 不与 `--send-ding` 同传，
`--must-read` 不用于定时公告。未传这两个参数时沿用原有发布行为。
## 入群审批与群身份 ## 入群审批与群身份
plugins/codex/plugins/dingtalk-workspace/skills/dingtalk-chat/references/chat/message-media.md
+27 -4
View File
@@ -2,9 +2,32 @@
> 返回入口：[DingTalk Chat Skill](../../SKILL.md) > 返回入口：[DingTalk Chat Skill](../../SKILL.md)
只用于位置、联系人名片、底层 mediaId/fileId 和消息资源下载。普通文本、Markdown、文件、 用于本地图文、图片路径错误、位置、联系人名片及消息资源下载。普通文本和文件发送按根 Skill 路由。
图片、音频和视频发送继续按根 Skill 使用 `+dm`、`+send-to-group` 或 `+messages-send --file`，
不读取本文件。 ## 发送本地图文
用户要求将图片与文字放在同一条消息中时，使用 `+messages-send --markdown`；要求发送文件附件时使用 `--file`。
1. **准备图片。** 取得用户附件的真实路径，确认执行 DWS 的进程能够读取。图片引用使用该进程工作目录内的相对路径；任务工作区与工具执行目录可能不同，以实际执行环境为准。
2. **组织正文。** 用 `![图片说明](相对路径)` 插入图片，保持用户指定的文字、图片顺序。例如：
```markdown
请看这张图片：
![现场照片](uploads/photo.png)
以上是今天的现场情况。
```
示例路径替换为第一步确认的图片路径。
3. **发送。** 将正文传给 `dws chat +messages-send --markdown`，CLI 自动上传图片并生成内联图文。接收对象、发送身份及确认要求沿用根 Skill 的发送流程。
4. **验收。** 返回 `openTaskId` 时，用 `+messages-query-send-status` 查询投递结果；根据实际状态报告已发送、处理中或失败。成功后简洁说明发送对象和内容，群名、人名用于展示，内部 ID 用于后续调用。
### 图片读取失败
文件不存在时核对附件位置与执行目录映射；无读取权限时检查进程访问权限；需要相对路径时按已确认的执行目录转换。工作目录位置从宿主执行上下文获取，修正后重试。可控制执行目录时，在同一次 shell 调用中切换到图片所在目录再执行；工具转发场景使用宿主提供的路径映射。若仍无法访问，向用户说明附件读取受阻及所需操作。用户可见回复仅包含业务结果、必要的失败原因和下一步；文件定位与工具诊断在内部完成。
`--dry-run` 的 `imageCount` 只表示识别到图片引用；可读性需实际检查。收到发送任务回执后，继续查询原任务，避免重复投递。
进展反馈围绕发送结果；仅在需要用户协助时说明具体障碍和所需操作。
## 默认边界 ## 默认边界
@@ -72,7 +95,7 @@ dws chat +messages-resource-download --type mediaId --resource-id <mediaId> \
## 完成与错误 ## 完成与错误
- 查询并下载时同时检查消息完整性和每项下载 ledger；单项失败不抹掉已取得消息。 - 查询并下载时同时检查消息完整性和每项下载 ledger；单项失败不抹掉已取得消息。
- 文件/音视频发送失败先确认工作目录内相对路径可读，不恢复独立上传再提取 mediaId 的旧默认链路。 - 文件/音视频读取失败按上面的“图片读取失败”流程核对路径。
- 位置参数不完整时先向用户确认，不猜经纬度或缩略图。 - 位置参数不完整时先向用户确认，不猜经纬度或缩略图。
- 名片发送失败时确认 `--contact-id` 是 openDingTalkId。 - 名片发送失败时确认 `--contact-id` 是 openDingTalkId。
- 下载目标存在时默认停止；只有用户明确允许覆盖时才传 `--overwrite`。 - 下载目标存在时默认停止；只有用户明确允许覆盖时才传 `--overwrite`。
plugins/codex/plugins/dingtalk-workspace/skills/dingtalk-contact/SKILL.md
+3 -2
View File
@@ -53,6 +53,7 @@ metadata:
| "按 userId 查详情" | `dws contact user get --ids <userId1>,<userId2>,...`（多个并行） | | "按 userId 查详情" | `dws contact user get --ids <userId1>,<userId2>,...`（多个并行） |
| "完整手机号反查用户" | `dws contact user search-mobile --mobile <手机号>` | | "完整手机号反查用户" | `dws contact user search-mobile --mobile <手机号>` |
| "按开放钉钉号ID（openDingTalkId）取 userId" | `dws contact user get-by-open-dingtalk-id --id <openDingTalkId>` | | "按开放钉钉号ID（openDingTalkId）取 userId" | `dws contact user get-by-open-dingtalk-id --id <openDingTalkId>` |
| "按手机号或钉钉号查 openDingTalkId" | `dws contact user get-open-dingtalk-id --keyword <手机号|钉钉号>`（企业需在能力灰度名单内） |
| "我的好友 / 好友列表 / 有哪些好友" | `dws contact +friend-list` | | "我的好友 / 好友列表 / 有哪些好友" | `dws contact +friend-list` |
| "好友申请 / 谁加我 / pending 好友请求" | `dws contact +friend-request-list` | | "好友申请 / 谁加我 / pending 好友请求" | `dws contact +friend-request-list` |
| "加好友 / 发送好友申请 / 添加某人为好友" | `dws contact +friend-request-send --to <openDingTalkId>` | | "加好友 / 发送好友申请 / 添加某人为好友" | `dws contact +friend-request-send --to <openDingTalkId>` |
@@ -119,7 +120,7 @@ metadata:
**触发**：好友列表、好友申请、加好友、同意/拒绝申请、删除好友。 **触发**：好友列表、好友申请、加好友、同意/拒绝申请、删除好友。
1. **获取 openDingTalkId（必须）**：好友命令全部以 **开放钉钉号ID（openDingTalkId）** 为身份键。openDingTalkId 的来源：①好友域自身数据——`dws contact +friend-list --format json` / `dws contact +friend-request-list --format json` 返回项的 `openDingTalkId` 字段，或好友事件消息体（`user_contact_friend_request_received` 的 `src/dest_open_dingtalk_id`、`user_contact_friend_added` 的 `friend_open_dingtalk_id`）；②按姓名等关键词搜人——`dws contact user search --query "<姓名>" --format json`（search_contact_by_key_word）结果同时返回 `userId` 与 `openDingTalkId`。注意：`aisearch person` 与 `contact user get-by-dingtalk-id` 只返回 userId、**取不到 openDingTalkId**；拿到 `openDingTalkId` 后如需 userId 再调 `dws contact user get-by-open-dingtalk-id --id <openDingTalkId> --format json`。 1. **获取 openDingTalkId（必须）**：好友命令全部以 **开放钉钉号ID（openDingTalkId）** 为身份键。openDingTalkId 的来源：①好友域自身数据——`dws contact +friend-list --format json` / `dws contact +friend-request-list --format json` 返回项的 `openDingTalkId` 字段，或好友事件消息体（`user_contact_friend_request_received` 的 `src/dest_open_dingtalk_id`、`user_contact_friend_added` 的 `friend_open_dingtalk_id`）；②按姓名等关键词搜人——`dws contact user search --query "<姓名>" --format json`（search_contact_by_key_word）结果同时返回 `userId` 与 `openDingTalkId`；③按手机号或钉钉号反查——`dws contact user get-open-dingtalk-id --keyword <手机号|钉钉号> --format json`（11 位数字自动按手机号匹配，其他按钉钉号；仅灰度名单内企业可用，未开通时返回 ability_not_full_open）。注意：`aisearch person` 只返回 userId、**取不到 openDingTalkId**；拿到 `openDingTalkId` 后如需 userId 再调 `dws contact user get-by-open-dingtalk-id --id <openDingTalkId> --format json`。
2. **查好友（必须）**：`dws contact +friend-list --format json` 返回当前登录用户的好友名单（含昵称 nick、备注名 alias）、好友状态与分页信息；`dws contact +friend-request-list --format json` 返回收到的好友申请（含申请人昵称 nick、申请留言、状态）与 pending 数量。向用户展示列表时优先用 nick / alias 标识好友，openDingTalkId 非必要不展示；汇报申请 status 时必须翻译为中文状态（1=待接受、3=已成为好友），不要直接显示数字。 2. **查好友（必须）**：`dws contact +friend-list --format json` 返回当前登录用户的好友名单（含昵称 nick、备注名 alias）、好友状态与分页信息；`dws contact +friend-request-list --format json` 返回收到的好友申请（含申请人昵称 nick、申请留言、状态）与 pending 数量。向用户展示列表时优先用 nick / alias 标识好友，openDingTalkId 非必要不展示；汇报申请 status 时必须翻译为中文状态（1=待接受、3=已成为好友），不要直接显示数字。
3. **写操作（必须）**：发送申请 `dws contact +friend-request-send --to <openDingTalkId> --remark "<验证留言>" --format json`；同意 `dws contact +friend-request-accept --from <openDingTalkId> --format json`；拒绝 `dws contact +friend-request-reject --from <openDingTalkId> --format json`；删除好友 `dws contact +friend-remove --friend <openDingTalkId> --format json`（最后一条为不可逆高风险写操作，**必须先取得用户明确确认**）。 3. **写操作（必须）**：发送申请 `dws contact +friend-request-send --to <openDingTalkId> --remark "<验证留言>" --format json`；同意 `dws contact +friend-request-accept --from <openDingTalkId> --format json`；拒绝 `dws contact +friend-request-reject --from <openDingTalkId> --format json`；删除好友 `dws contact +friend-remove --friend <openDingTalkId> --format json`（最后一条为不可逆高风险写操作，**必须先取得用户明确确认**）。
@@ -133,7 +134,7 @@ metadata:
- 查询直属主管/上下级时，如果 `contact user get` 没返回明确主管字段，必须继续 `dws aisearch person --query "<完整姓名或工号>" --dimension supervisor --format json`，不要停在"可能需要进一步查询"。 - 查询直属主管/上下级时，如果 `contact user get` 没返回明确主管字段，必须继续 `dws aisearch person --query "<完整姓名或工号>" --dimension supervisor --format json`，不要停在"可能需要进一步查询"。
- 多个同名候选时，批量 `contact user get --ids id1,id2,... --format json` 获取部门/职位后再消歧；不要默认取第一个。 - 多个同名候选时，批量 `contact user get --ids id1,id2,... --format json` 获取部门/职位后再消歧；不要默认取第一个。
- 用户查询企业角色、角色ID、角色成员，或“管理员/财务/HR/主管”等角色类型人员时，走 `contact label list/get/list-members`；不要用 `dept list-members` 筛字段替代。 - 用户查询企业角色、角色ID、角色成员，或“管理员/财务/HR/主管”等角色类型人员时，走 `contact label list/get/list-members`；不要用 `dept list-members` 筛字段替代。
- 好友命令（`+friend-*`）全部以 **openDingTalkId** 为身份键，不是 userId 也不是钉钉号；openDingTalkId 可从 `+friend-list` / `+friend-request-list` 响应、好友事件消息体，或 `contact user search`（按关键词搜人，同时返回 userId 与 openDingTalkId）取得；`aisearch person` / `get-by-dingtalk-id` 只返回 userId、取不到 openDingTalkId。 - 好友命令（`+friend-*`）全部以 **openDingTalkId** 为身份键，不是 userId 也不是钉钉号；openDingTalkId 可从 `+friend-list` / `+friend-request-list` 响应、好友事件消息体，或 `contact user search`（按关键词搜人，同时返回 userId 与 openDingTalkId）取得；`aisearch person` 只返回 userId、取不到 openDingTalkId。
- `+friend-remove` 为不可逆高风险写操作，执行前**必须**向用户展示目标 openDingTalkId 并获取明确确认；确认后才可加 `--yes`。 - `+friend-remove` 为不可逆高风险写操作，执行前**必须**向用户展示目标 openDingTalkId 并获取明确确认；确认后才可加 `--yes`。
## 跨产品协作 ## 跨产品协作
plugins/codex/plugins/dingtalk-workspace/skills/dingtalk-contact/references/contact.md
+27 -2
View File
@@ -74,10 +74,35 @@ Flags:
--id string 开放钉钉号ID（openDingTalkId）(必填) --id string 开放钉钉号ID（openDingTalkId）(必填)
Notes: Notes:
- openDingTalkId 是开放平台场景下、用于标识两个 uid 关系的开放钉钉号ID，通常出现在好友事件等业务消息体中 - openDingTalkId 是开放平台场景下、用于标识两个 uid 关系的开放钉钉号ID，通常出现在好友事件等业务消息体中
- openDingTalkId 与钉钉号（dingtalkId，如 zhangsan）不是同一概念；已知普通钉钉号时请使用 `contact user get-by-dingtalk-id` - openDingTalkId 与钉钉号（dingtalkId，如 zhangsan）不是同一概念，二者不可互换
- 本命令别名必须使用 `get-user-by-open-dingtalk-id`，禁止其他变体 - 本命令别名必须使用 `get-user-by-open-dingtalk-id`，禁止其他变体
``` ```
#### 按手机号或钉钉号获取 openDingTalkId
```
Usage:
dws contact user get-open-dingtalk-id [flags]
Aliases:
get-open-dingtalk-id, get-open-id
Example:
dws contact user get-open-dingtalk-id --keyword 13800138000
dws contact user get-open-id --keyword zhangsan # 别名
Flags:
--keyword string 手机号（11位数字）或钉钉号 (必填)
Returns:
result.userList[].openDingTalkId string 开放钉钉号ID（与查询操作人成对）
result.userList[].nick string 用户昵称
result.userList[].exclusive bool 是否专属（企业）账号
result.userList[].exclusiveOrgName string 专属账号所属企业名，非专属账号不返回该字段
result.userList[].isFriend bool 与操作人是否为好友
success / errorCode / errorMsg
Notes:
- 输入自动识别：11 位纯数字按手机号匹配，其他按钉钉号匹配
- 仅对灰度名单内的企业开放；未开通企业的调用被明确拒绝（errorCode=ability_not_full_open），而非返回空结果
- 受频次限制（单用户每日上限、企业每日上限），超出时报 CONCURRENT_ERROR
- 已知 openDingTalkId 需要反查 userId 时用 `contact user get-by-open-dingtalk-id`
```
#### 批量获取用户详情 #### 批量获取用户详情
``` ```
Usage: Usage:
@@ -750,7 +775,7 @@ dws contact user get-by-open-dingtalk-id --id <openDingTalkId> --format json
- `label list-members` 需要先通过 `label list` 或 `label get` 获取 labelId，再用 --id 查询角色下的成员 - `label list-members` 需要先通过 `label list` 或 `label get` 获取 labelId，再用 --id 查询角色下的成员
- `user update-self` 用于更新当前用户自己的昵称/头像；头像 fileId 需先上传头像到钉盘获取 - `user update-self` 用于更新当前用户自己的昵称/头像；头像 fileId 需先上传头像到钉盘获取
- `account update` 用于更新企业账号用户信息；`--depts` 为 JSON 数组格式，头像 fileId 需先上传钉盘获取 - `account update` 用于更新企业账号用户信息；`--depts` 为 JSON 数组格式，头像 fileId 需先上传钉盘获取
- 好友命令（`+friend-*`）的身份键是 **openDingTalkId（开放钉钉号ID）**，与 userId、钉钉号（dingtalkId）均不同；openDingTalkId 可从 `+friend-list` / `+friend-request-list` 响应的 `openDingTalkId` 字段、好友事件消息体，或 `user search`（按关键词搜人，结果同时返回 userId 与 openDingTalkId）取得，`aisearch person` / `user get-by-dingtalk-id` 只返回 userId、取不到 openDingTalkId；拿到 openDingTalkId 后可用 `user get-by-open-dingtalk-id` 反查 userId - 好友命令（`+friend-*`）的身份键是 **openDingTalkId（开放钉钉号ID）**，与 userId、钉钉号（dingtalkId）均不同；openDingTalkId 可从 `+friend-list` / `+friend-request-list` 响应的 `openDingTalkId` 字段、好友事件消息体，或 `user search`（按关键词搜人，结果同时返回 userId 与 openDingTalkId）取得，`aisearch person` 只返回 userId、取不到 openDingTalkId；拿到 openDingTalkId 后可用 `user get-by-open-dingtalk-id` 反查 userId
- `+friend-list` 与 `+friend-request-list` 支持分页：翻页时把上一页返回的 `cursor` 传入 `--cursor`（或从统一 envelope 的 `meta.pagination.next_token` 取）；`hasMore=true` 表示还有下一页 - `+friend-list` 与 `+friend-request-list` 支持分页：翻页时把上一页返回的 `cursor` 传入 `--cursor`（或从统一 envelope 的 `meta.pagination.next_token` 取）；`hasMore=true` 表示还有下一页
- `+friend-request-list` 查询后未读申请会被标记为已读，属正常副作用 - `+friend-request-list` 查询后未读申请会被标记为已读，属正常副作用
- `+friend-remove` 不可逆：删除后需重新发起好友申请才可恢复，执行前必须确认 - `+friend-remove` 不可逆：删除后需重新发起好友申请才可恢复，执行前必须确认
plugins/codex/plugins/dingtalk-workspace/skills/dingtalk-event/SKILL.md
+1 -1
View File
@@ -69,7 +69,7 @@ OA 七个 EventKey 使用 `ruleType=all`、`filterRule={}`，不接受目标或
- 单事件 ready：`[event] ready event_key=<key> bus_pid=<pid> subscribe_id=<id>`。 - 单事件 ready：`[event] ready event_key=<key> bus_pid=<pid> subscribe_id=<id>`。
- 多事件先逐条输出 subscription，全部就绪后输出 `[event] ready event_count=<n> bus_pid=<pid>`。等 ready，不用 `sleep` 猜测。 - 多事件先逐条输出 subscription，全部就绪后输出 `[event] ready event_count=<n> bus_pid=<pid>`。等 ready，不用 `sleep` 猜测。
- 有界任务用 `--max-events N`/`--duration 10m`；干净退出会取消本次新建订阅。无界任务由宿主持续读 stdout；用 SIGTERM 或 bounded exit，不用 `kill -9`。 - 有界任务用 `--max-events N`/`--duration 10m`；干净退出会取消本次新建订阅。无界任务由宿主持续读 stdout；用 SIGTERM 或 bounded exit，不用 `kill -9`。
- 自发消息会被 self-loop 过滤。回复时把真实 `conversation_id`/`sender_open_dingtalk_id` 交给 `dws chat +messages-send`，不从显示名猜 ID。 - 自发消息会被 self-loop 过滤。按已授权规则决定是否回复；回复用真实 `conversation_id`/`sender_open_dingtalk_id`，见[回复交接](references/event-im-output.md)。
- 扁平消息/动作字段按事件类型读取：已读为 `reader_open_dingtalk_id`，撤回为 `recaller_open_dingtalk_id`，回应为 `reaction_name`、`operation_type`。媒体优先通过聊天读取命令加 `--download-resources`，已知消息 ID 用 `dws chat message download-media`。 - 扁平消息/动作字段按事件类型读取：已读为 `reader_open_dingtalk_id`，撤回为 `recaller_open_dingtalk_id`，回应为 `reaction_name`、`operation_type`。媒体优先通过聊天读取命令加 `--download-resources`，已知消息 ID 用 `dws chat message download-media`。
- OA 扁平事件提供审批实例、任务和状态字段；字段差异、原始回退条件及与 OA 命令的稳定 ID 交接以 [OA 事件参考](references/event-oa.md) 为准。 - OA 扁平事件提供审批实例、任务和状态字段；字段差异、原始回退条件及与 OA 命令的稳定 ID 交接以 [OA 事件参考](references/event-oa.md) 为准。
- Todo 扁平事件提供 `task_id`、标题、角色、状态阶段和时间字段；用真实 `task_id` 交给 `dws todo`，字段差异见 [Todo 事件参考](references/event-todo.md)。 - Todo 扁平事件提供 `task_id`、标题、角色、状态阶段和时间字段；用真实 `task_id` 交给 `dws todo`，字段差异见 [Todo 事件参考](references/event-todo.md)。
plugins/codex/plugins/dingtalk-workspace/skills/dingtalk-event/references/event-im-output.md
+8
View File
@@ -25,6 +25,14 @@ Agent 默认使用 `--flatten -f ndjson`，顶层直接读取字段，不再 `fr
## 事件驱动回复的精确 ID 映射 ## 事件驱动回复的精确 ID 映射
监听本身不构成回复授权；已授权的自动回复按当前有效规则执行，不因使用监听命令而停用。仅要求监听、记录或分析时，不向事件来源自动发送回复或占位卡；已读或 reaction 默认不触发回复。
确定需要回复后读取 [回复占位与流式](../../dingtalk-chat/references/card/a2ui.md)，由接入 Agent 的宿主落实启动钩子。定时通知和完整结果交付按主动发送处理；回复进度目标与最终交付目标分别核实，不因收到事件就向交付目标发占位。
使用该卡片回复流程需已安装 `dingtalk-chat`；按需安装时请同时选择该 Skill。
下表是普通文本回复的目标映射；A2UI 创建和更新使用上述参考中的命令。
<!-- DWS_EVENT_CHAT_HANDOFF_START --> <!-- DWS_EVENT_CHAT_HANDOFF_START -->
| event field | exact chat target | | event field | exact chat target |
|---|---| |---|---|
plugins/codex/plugins/dingtalk-workspace/skills/dingtalk-misc/references/oa-create.md
+1 -1
View File
@@ -165,7 +165,7 @@ dws oa approval detail --instance-id <processInstanceId> --format json
dws oa approval forecast-process --process-code <processCode> --dept-id <deptId> --form-values '<JSON对象>' --format json dws oa approval forecast-process --process-code <processCode> --dept-id <deptId> --form-values '<JSON对象>' --format json
``` ```
简单模式的 `process-code`、`dept-id`、`form-values` 必须一次传齐。先从当前用户信息确定 `deptId`；不得用一次缺参调用来发现约束。 简单模式的 `process-code`、`dept-id`、`form-values` 必须一次传齐；不得用一次缺参调用来发现约束。`deptId` 必须已核验：先从当前用户信息确定真实 `deptId`——`dws contact user get-self` 读 `orgEmployeeModel.depts[].deptId`，多部门时经用户确认；`-1` 仅代表根部门，禁止照抄示例。
检查 `workflowActivityRuleVOs`： 检查 `workflowActivityRuleVOs`：
plugins/codex/plugins/dingtalk-workspace/skills/dingtalk-misc/references/oa.md
+1
View File
@@ -150,6 +150,7 @@ dws oa approval list-by-admin --process-code <processCode> --start "<ISO-8601>"
| 为当前用户授权下载 | `dws oa approval attachment authorize-download` | `fileInfos` 最多 10 项；不返回下载链接 | | 为当前用户授权下载 | `dws oa approval attachment authorize-download` | `fileInfos` 最多 10 项；不返回下载链接 |
| 授权审批内预览 | `dws oa approval attachment authorize-preview` | `fileIds` 最多 20 项；不等于下载授权 | | 授权审批内预览 | `dws oa approval attachment authorize-preview` | `fileIds` 最多 20 项；不等于下载授权 |
| 上传本地审批附件 | `dws oa approval attachment upload` | 返回附件元数据，供创建审批字段使用 | | 上传本地审批附件 | `dws oa approval attachment upload` | 返回附件元数据，供创建审批字段使用 |
| 上传本地审批图片 | `dws oa approval image upload` | 返回 mediaIdV2，供组装 DDPhotoField 图片控件 value |
附件实例也必须来自用户指定的角色来源。生成下载链接成功不能证明下载授权成功，反之亦然。 附件实例也必须来自用户指定的角色来源。生成下载链接成功不能证明下载授权成功，反之亦然。
plugins/codex/plugins/dingtalk-workspace/skills/dingtalk-misc/references/oa/oa-form-components.md
+16 -8
View File
@@ -194,10 +194,10 @@
| 属性 | 说明 | | 属性 | 说明 |
|------|----------------------------------------------------| |------|----------------------------------------------------|
| `componentName` | `InnerContactField` | | `componentName` | `InnerContactField` |
| value 格式 | userId 字符串，多人时为 JSON 数组字符串 | | value 格式 | JSON 数组字符串（userId 数组）；单选传单元素数组，多选传多元素数组 |
| 示例（单选） | `"user123"` | | 示例（单选） | `'["user123"]'` |
| 示例（多选） | `'["userId1","userId2"]'` | | 示例（多选） | `'["userId1","userId2"]'` |
| 约束 | `choice: "0"` 单选 / `"1"` 多选；userId 须为**当前组织下在职成员** | | 约束 | `choice: "0"` 单选 / `"1"` 多选；**单选也必须传单元素数组**，裸 userId 字符串会传值异常；userId 须为**当前组织下在职成员** |
```json ```json
{ "name": "项目负责人", "value": "[\"userId1\",\"userId2\"]" } { "name": "项目负责人", "value": "[\"userId1\",\"userId2\"]" }
@@ -234,19 +234,27 @@
### DDPhotoField（图片控件） ### DDPhotoField（图片控件）
> **支持通过图片 URL 提交，不支持本地文件上传。** 如果用户已有图片 URL（如公网可访问的图片链接），可直接填入 value 提交。CLI 尚未封装本地文件上传到钉盘 CDN 的流程，若用户只有本地文件而非 URL，需告知用户在钉钉客户端补充。 > **[支持] 已支持通过 CLI 提交本地图片。** 本地图片先用 `dws oa approval image upload --file <path>` 上传获取 mediaIdV2，再将 mediaIdV2 组装为 value 随 `create-instance` 提交；用户已有公网图片 URL 时无需上传，可直接填入 value 提交。
| 属性 | 说明 | | 属性 | 说明 |
|------|------| |------|------|
| `componentName` | `DDPhotoField` | | `componentName` | `DDPhotoField` |
| value 格式 | URL 数组转义字符串，即使只有一个 URL 也需数组形式 | | value 格式 | 数组转义字符串，元素为图片 URL 或 mediaIdV2，即使只有一个元素也需数组形式 |
| 示例 | `"[\"http://example.com/img1.jpg\",\"http://example.com/img2.jpg\"]"` | | 示例 | `"[\"http://example.com/img1.jpg\",\"http://example.com/img2.jpg\"]"` |
| 约束 | 支持 URL 直接提交；**不支持本地文件上传**（CLI 未封装钉盘上传流程）； | | 约束 | 支持 URL 或 mediaIdV2 直接提交；本地图片先用 `dws oa approval image upload --file <path>` 取 mediaIdV2（jpg/jpeg/png/gif/webp/bmp，≤2MB 直传，>2MB 自动压缩，>10MB 拒绝） |
URL 取值示例：
```json ```json
{ "name": "图片", "value": "[\"http://example.com/photo.jpg\"]" } { "name": "图片", "value": "[\"http://example.com/photo.jpg\"]" }
``` ```
mediaIdV2 取值示例（由 `dws oa approval image upload` 返回）：
```json
{ "name": "图片", "value": "[\"<mediaIdV2>\"]" }
```
### DDAttachment（附件控件） ### DDAttachment（附件控件）
> **[支持] 已支持通过 CLI 提交附件控件。** 采用两步流程：先用 `dws oa approval attachment upload --file <path>` 上传本地文件，获取 spaceId、fileName、fileSize、fileType、fileId；再将这些字段组装为 DDAttachment value（JSON 数组转义字符串）随 `create-instance` 提交。 > **[支持] 已支持通过 CLI 提交附件控件。** 采用两步流程：先用 `dws oa approval attachment upload --file <path>` 上传本地文件，获取 spaceId、fileName、fileSize、fileType、fileId；再将这些字段组装为 DDAttachment value（JSON 数组转义字符串）随 `create-instance` 提交。
@@ -452,7 +460,7 @@ extValue = JSON.stringify({
> **IMPORTANT：** > **IMPORTANT：**
> - `bizAlias` 不组装（MCP formComponentValues 无此字段，服务端按 id 匹配）；**不构造 `repairCheckTime` 条目**（服务端回填字段，PC 提交数据无此字段名）。 > - `bizAlias` 不组装（MCP formComponentValues 无此字段，服务端按 id 匹配）；**不构造 `repairCheckTime` 条目**（服务端回填字段，PC 提交数据无此字段名）。
> - 班次匹配与资格判定一律以服务端为准：`supply-plans` 空 → 转告终止；多班次 → 用户按 planTip 选择；`supply-check` qualify=false → 转告 title/desc 终止。 > - 班次匹配与资格判定一律以服务端为准：`supply-plans` 空 → 转告终止；多班次 → 用户按 planTip 选择；`supply-check` qualify=false → 转告 title/desc 终止。
> - 补卡理由控件（TextareaField）是否必收以 form-schema 的 required 为准（控件必填性由模板配置决定）；图片控件（DDPhotoField）一期跳过并提示客户端补充。 > - 补卡理由控件（TextareaField）是否必收以 form-schema 的 required 为准（控件必填性由模板配置决定）；图片控件（DDPhotoField）如需提交，先用 `dws oa approval image upload --file <path>` 取 mediaIdV2 再组装 value。
> - 模板流程不固定（自选审批人只是常见配置之一，管理员可自由改为主管链/条件分支等）：forecast 返回 `workflowActivityRuleVOs[].targetSelect=true` 且 `workflowActor.required=true` 的节点时**必须选人**并组装 `targetSelectActioners`（actionerKey=`workflowActor.actorKey`，漏选会创建成功但流转挂起）；无自选节点则不需要选人，一切以 forecast 返回为准。 > - 模板流程不固定（自选审批人只是常见配置之一，管理员可自由改为主管链/条件分支等）：forecast 返回 `workflowActivityRuleVOs[].targetSelect=true` 且 `workflowActor.required=true` 的节点时**必须选人**并组装 `targetSelectActioners`（actionerKey=`workflowActor.actorKey`，漏选会创建成功但流转挂起）；无自选节点则不需要选人，一切以 forecast 返回为准。
> - `timeZoneInfo` **不本地拼接**（可选字段）：服务端 `supply-plans` 响应不含时区数据，PC 真实数据不含亦可成功。多时区 V2 灰度（multiTimeZoneV2）与补卡次数 trial（enableSupplyTimes）一期不支持。 > - `timeZoneInfo` **不本地拼接**（可选字段）：服务端 `supply-plans` 响应不含时区数据，PC 真实数据不含亦可成功。多时区 V2 灰度（multiTimeZoneV2）与补卡次数 trial（enableSupplyTimes）一期不支持。
@@ -598,7 +606,7 @@ children 条目（位于容器 value 字符串内部，`key`=子控件 props.id
| OCR 文本识别 | `OcrTextField` | 需要客户端 OCR 交互 | | OCR 文本识别 | `OcrTextField` | 需要客户端 OCR 交互 |
| OCR 身份证识别 | `OcrIdCardField` | 需要客户端 OCR 交互 | | OCR 身份证识别 | `OcrIdCardField` | 需要客户端 OCR 交互 |
> **部分支持的控件：** `DDPhotoField`（图片控件）**支持通过 URL 直接提交**，但不支持本地文件上传（CLI 未封装钉盘 CDN 上传流程）。若用户只有本地文件，需告知在钉钉客户端补充。详见本文 [DDPhotoField](#ddphotofield图片控件) 章节。 > **`DDPhotoField`（图片控件）已支持通过 CLI 提交：** 本地图片先用 `dws oa approval image upload --file <path>` 上传取 mediaIdV2，再组装 value（数组转义字符串）随 `create-instance` 提交；公网图片 URL 可直接填入 value 提交。详见本文 [DDPhotoField](#ddphotofield图片控件) 章节。
> **套件类控件（大部分暂不支持）** — `InvoiceField`（发票）、`RecipientAccountField`（收款账户）等业务套件控件当前暂不支持通过 CLI 发起，包含这些控件的审批模板请直接在钉钉客户端操作。**例外：`DDHolidayField`（请假套件）、`DDBizSuite · attendance.supply`（补卡套件）、`DDBizSuite · attendance.goout`（外出套件）与 `DDBizSuite · attendance.batchovertime`（加班套件）已支持**，按上方章节与 [oa-leave.md](oa-leave.md) / [oa-supply.md](oa-supply.md) / [oa-goout.md](oa-goout.md) / [oa-overtime.md](oa-overtime.md) 工作流发起。 > **套件类控件（大部分暂不支持）** — `InvoiceField`（发票）、`RecipientAccountField`（收款账户）等业务套件控件当前暂不支持通过 CLI 发起，包含这些控件的审批模板请直接在钉钉客户端操作。**例外：`DDHolidayField`（请假套件）、`DDBizSuite · attendance.supply`（补卡套件）、`DDBizSuite · attendance.goout`（外出套件）与 `DDBizSuite · attendance.batchovertime`（加班套件）已支持**，按上方章节与 [oa-leave.md](oa-leave.md) / [oa-supply.md](oa-supply.md) / [oa-goout.md](oa-goout.md) / [oa-overtime.md](oa-overtime.md) 工作流发起。
plugins/codex/plugins/dingtalk-workspace/skills/dingtalk-misc/references/oa/oa-supply.md
+2 -2
View File
@@ -14,7 +14,7 @@
2.【模板详情】dws oa approval form-schema --process-code <code> 2.【模板详情】dws oa approval form-schema --process-code <code>
→ 下钻 DDBizSuite（bizType=="attendance.supply"）的 children 取子控件 → 下钻 DDBizSuite（bizType=="attendance.supply"）的 children 取子控件
DDDateField（bizAlias=="userCheckTime"：id/format/label，format 默认 yyyy-MM-dd HH:mm） DDDateField（bizAlias=="userCheckTime"：id/format/label，format 默认 yyyy-MM-dd HH:mm）
→ 确认补卡理由控件（TextareaField，是否必收以 form-schema 的 required 为准）；图片控件（DDPhotoField）一期跳过并提示客户端补充 → 确认补卡理由控件（TextareaField，是否必收以 form-schema 的 required 为准）；图片控件（DDPhotoField）如需提交，先用 `dws oa approval image upload --file <path>` 取 mediaIdV2 再组装 value
3.【定位缺卡（可选）】用户未给时间 → dws attendance record get --user <userId> --date <某日> 3.【定位缺卡（可选）】用户未给时间 → dws attendance record get --user <userId> --date <某日>
（单日粒度，近 N 天按日循环查询）辅助定位缺卡时间 （单日粒度，近 N 天按日循环查询）辅助定位缺卡时间
4.【班次匹配】dws attendance approve supply-plans --time "<yyyy-MM-dd HH:mm>" 4.【班次匹配】dws attendance approve supply-plans --time "<yyyy-MM-dd HH:mm>"
@@ -43,6 +43,6 @@
> **IMPORTANT：** 班次匹配与资格判定一律以服务端（supply-plans / supply-check）为准；value 必须按子控件 `format` 格式化（禁硬编码）；步骤 9 必须走 `--request` 高级模式。流程与选人无补卡特有逻辑，一律按 [oa-create.md](../oa-create.md) 的「创建闭环」与「流程预测与选人 → 执行前确认 → 创建与写后验证」执行。 > **IMPORTANT：** 班次匹配与资格判定一律以服务端（supply-plans / supply-check）为准；value 必须按子控件 `format` 格式化（禁硬编码）；步骤 9 必须走 `--request` 高级模式。流程与选人无补卡特有逻辑，一律按 [oa-create.md](../oa-create.md) 的「创建闭环」与「流程预测与选人 → 执行前确认 → 创建与写后验证」执行。
模板不支持 CLI 发起（含图片控件需上传证据等）时的 `submitUrl` 兜底与链接展示规范，见 [oa-create.md](../oa-create.md)「考勤审批套件」章节的 submitUrl 引导规范。 模板不支持 CLI 发起（不含图片控件——补卡图片证据可用 `dws oa approval image upload` 取 mediaIdV2 提交）时的 `submitUrl` 兜底与链接展示规范，见 [oa-create.md](../oa-create.md)「考勤审批套件」章节的 submitUrl 引导规范。
字段级规范见 [oa-form-components.md](oa-form-components.md) 的 DDBizSuite（补卡套件）章节。 字段级规范见 [oa-form-components.md](oa-form-components.md) 的 DDBizSuite（补卡套件）章节。
plugins/codex/plugins/dingtalk-workspace/skills/dingtalk-misc/scripts/oa_create_preflight.py
+2 -2
View File
@@ -18,10 +18,10 @@ VALUE_KINDS = {
"PhoneField": "phone_string", "PhoneField": "phone_string",
"IdCardField": "id_card_string", "IdCardField": "id_card_string",
"MoneyField": "decimal_string", "MoneyField": "decimal_string",
"InnerContactField": "user_id_or_json_array", "InnerContactField": "user_id_json_array",
"DepartmentField": "dept_id_or_json_array", "DepartmentField": "dept_id_or_json_array",
"AddressField": "address_json_array_string", "AddressField": "address_json_array_string",
"DDPhotoField": "url_json_array_string", "DDPhotoField": "url_or_media_id_json_array_string",
"DDAttachment": "attachment_json_array_string", "DDAttachment": "attachment_json_array_string",
"StarRatingField": "number_string", "StarRatingField": "number_string",
"RelateField": "process_instance_id", "RelateField": "process_instance_id",
plugins/codex/plugins/dingtalk-workspace/skills/dingtalk-tag/SKILL.md
+3 -1
View File
@@ -12,6 +12,8 @@ metadata:
执行任何 `dws` 操作前，先完整读取 [`dingtalk-shared`](../dingtalk-shared/SKILL.md)。先用 [dingtalk-tag-index.md](references/dingtalk-tag-index.md) 路由；生命周期读取 [manage.md](references/manage.md)，自然语言创建/恢复/DSH 接入再读 [manage-and-connect.md](references/manage-and-connect.md)；能力资源读取 [capability.md](references/capability.md)；执行排障读取 [run.md](references/run.md)。 执行任何 `dws` 操作前，先完整读取 [`dingtalk-shared`](../dingtalk-shared/SKILL.md)。先用 [dingtalk-tag-index.md](references/dingtalk-tag-index.md) 路由；生命周期读取 [manage.md](references/manage.md)，自然语言创建/恢复/DSH 接入再读 [manage-and-connect.md](references/manage-and-connect.md)；能力资源读取 [capability.md](references/capability.md)；执行排障读取 [run.md](references/run.md)。
自行管理任务执行与回复的接入方，可按 [回复占位与流式](../dingtalk-chat/references/card/a2ui.md) 实现启动钩子和卡片更新。使用该流程需已安装 `dingtalk-chat`；按需安装时请同时选择该 Skill。DWS 直接托管本地 Agent 时，对已适配公开进度的 Agent，新连接默认发送 A2UI 占位并更新同一卡片，由运行时负责投递，模型不重复发卡；连接时指定 `--reply-mode text` 可只发最终文本。适配范围和首卡策略见 [接入说明](references/manage-and-connect.md)。
## 路由 ## 路由
| 用户意图 | 命令 | | 用户意图 | 命令 |
@@ -52,4 +54,4 @@ metadata:
- `manage login` 在内部完成 AuthCode 换票、在线身份核验，并保存精确 `corpId:userId` Profile；不得输出或转存 AuthCode/Token。只登录或仅保存 Profile 使用 `manage login`；真正接入本地 Agent/DSH 使用 `connect`。 - `manage login` 在内部完成 AuthCode 换票、在线身份核验，并保存精确 `corpId:userId` Profile；不得输出或转存 AuthCode/Token。只登录或仅保存 Profile 使用 `manage login`；真正接入本地 Agent/DSH 使用 `connect`。
- 删除不可逆；修改、发布、删除和 connect 按 Schema 的确认要求执行。 - 删除不可逆；修改、发布、删除和 connect 按 Schema 的确认要求执行。
- Channel 的 `reply` / `operator-private` 只供已绑定的本地 Adapter/DSH 机器协议使用，必须指定员工 Profile，正文只能走受限 stdin；不要为普通用户消息直接调用。 - Channel 仅保留 `capabilities` / `binding` 用于能力发现和绑定、访问判定。数字员工发送使用 `chat +messages-reply` / `chat +messages-send`，必须指定员工 Profile，并以 `--body-stdin --wait-delivery --employee-context` 传入受限正文与绑定上下文。DSH 要求 `chatDelivery=true`，缺少时提示升级 DWS。
plugins/codex/plugins/dingtalk-workspace/skills/dingtalk-tag/references/manage-and-connect.md
+8 -2
View File
@@ -14,6 +14,12 @@ connect 在接入 Agent 前调用服务端 bind，返回 ID 后持久保存。
## 接入普通本地 Agent ## 接入普通本地 Agent
本节回复模式仅适用于 DWS 直接托管的本地 Agent；外部宿主接入（`--channel dsh`）由宿主负责回复，详见下方“接入已有数字员工到 DSH”。
新建连接的回复模式默认是 `--reply-mode a2ui`；历史配置缺少回复模式时保持文本回复和原会话，重新 connect 可显式选择模式。对已适配公开进度接口的 Agent，DWS 接入运行时在调用模型前发送“思考中…”占位，并将公开阶段、工具开始/结束状态和答案更新到同一卡片；不展示内部推理或工具原始输入输出。执行面板默认收起，运行中显示生成动画，结束时移除；最终答案在面板外展示；超出单批容量的正文分段写入同一卡片，全部成功后才完结。未适配公开进度接口的 Agent、会话控制命令仍使用最终文本。
连接时指定 `--reply-mode text` 可跳过占位和卡片，只发送最终文本。首卡策略按连接配置确定，不根据自然语言临时推断；修改已运行连接的配置需先 stop，再按原绑定信息 connect。首卡创建失败或结果未确认时不启动模型、不自动回退；失败原因保留在任务账本中，连续失败写运行日志告警；核实未投递后可按需切换 text 模式重新发起任务。本地容量限制导致无法完整交付时，保留已投递内容并尝试以“完整结果未交付”结束卡片，不标记成功。其他卡片更新失败或结果未知时保留原卡并标记待核实，不重建、不自动重发最终文本；中断任务不自动重放，强制退出后不保证补发终态。
```bash ```bash
dws dingtalk-tag connect --agent-uuid <agentUuid> --channel codex --agent-workdir <directory> --daemon --alwayson --dry-run --format json dws dingtalk-tag connect --agent-uuid <agentUuid> --channel codex --agent-workdir <directory> --daemon --alwayson --dry-run --format json
dws dingtalk-tag connect --agent-uuid <agentUuid> --channel codex --agent-workdir <directory> --daemon --alwayson --yes --format json dws dingtalk-tag connect --agent-uuid <agentUuid> --channel codex --agent-workdir <directory> --daemon --alwayson --yes --format json
@@ -22,7 +28,7 @@ dws dingtalk-tag connect stop --agent-uuid <agentUuid> --format json
dws dingtalk-tag connect restart --agent-uuid <agentUuid> --format json dws dingtalk-tag connect restart --agent-uuid <agentUuid> --format json
``` ```
连接使用数字员工 Profile 启动 Event Consumer，调用与 dev connect 共用的 Agent 协议，最终以员工身份引用回复文本。后台结果只有在 ready 后才返回运行成功；不支持的 Agent 或缺失的依赖必须明确报错。 连接使用数字员工 Profile 启动 Event Consumer，调用与 dev connect 共用的 Agent 协议，以员工身份按回复模式更新 A2UI 卡片，或引用回复最终文本。后台结果只有在 ready 后才返回运行成功；不支持的 Agent 或缺失的依赖必须明确报错。
支持 `qoder/qoderwork/workbuddy/claudecode/codebuddy/codex/gemini/opencode/custom`；custom 使用 `--agent-cmd`，问题作为最后一个参数、stdout 作为答案。模型、工作目录、会话和权限参数沿用 dev connect，模型推理是否远端执行由 Agent 自身决定。 支持 `qoder/qoderwork/workbuddy/claudecode/codebuddy/codex/gemini/opencode/custom`；custom 使用 `--agent-cmd`，问题作为最后一个参数、stdout 作为答案。模型、工作目录、会话和权限参数沿用 dev connect，模型推理是否远端执行由 Agent 自身决定。
@@ -44,7 +50,7 @@ dws dingtalk-tag manage create \
--dry-run --format json --dry-run --format json
``` ```
create 只创建草稿并返回 `agentUuid`。名称、描述和主程序类型必填；必须显式传 `--type open_code|local_agent`，不可为空；部门可不传，由服务端补操作人的主任职部门。create 支持可选 --prompt；local_agent 创建时省略则由 DWS 自动保存默认人设，发布时仍对历史草稿兜底，已有非空人设保持不变。open_code 省略时仅提醒发布前补齐，不阻断草稿创建。显式空字符串或纯空白无效。其他发布所需配置由服务端校验。创建成功后必须立即保存 `agentUuid`；后续失败只从 detail/save-draft/publish 恢复。 create 只创建草稿并返回 `agentUuid`。名称、描述和主程序类型必填；必须显式传 `--type open_code|local_agent`，不可为空；部门可不传，由服务端补操作人的主任职部门。create 支持可选 --prompt；local_agent 创建时省略则由 DWS 自动保存默认人设，发布时不会再写入人设。open_code 省略时仅提醒发布前补齐，不阻断草稿创建。显式空字符串或纯空白无效。其他发布所需配置由服务端校验。创建成功后必须立即保存 `agentUuid`；后续失败只从 detail/save-draft/publish 恢复。
## 修改：按字段更新 ## 修改：按字段更新
plugins/codex/plugins/dingtalk-workspace/skills/dingtalk-tag/references/manage.md
+1 -1
View File
@@ -102,7 +102,7 @@ Usage:
dws dingtalk-tag manage publish --agent-uuid <agentUuid> dws dingtalk-tag manage publish --agent-uuid <agentUuid>
``` ```
发布当前已保存的完整草稿。`local_agent` 无需用户配置平台人设；DWS 在发布前读取草稿，仅在人设缺失时自动保存默认人设，已有非空人设不会被覆盖。`open_code` 不自动补人设。预览只列出条件补齐与发布计划，不访问远端。若默认人设保存成功而发布失败，默认值保留在草稿，查询草稿后再重试。其他发布所需配置由服务端校验。创建默认发送 `mention_only`；历史草稿缺少响应模式时，先通过 `save-draft --response-mode mention_only` 补齐。 发布当前已保存的完整草稿。DWS 在发布前读取草稿；如果返回 `updateUserId`，必须与当前操作人的 userId 一致，否则拒绝发布。旧草稿缺少更新人时兼容放行，无法提供同样的防误发保障。`publish` 不会修改草稿或自动补人设；`local_agent` 无需用户配置平台人设。预览只列出检查与发布计划，不访问远端。其他发布所需配置由服务端校验。创建默认发送 `mention_only`；历史草稿缺少响应模式时，先通过 `save-draft --response-mode mention_only` 补齐。
## delete — 删除 ## delete — 删除
plugins/codex/plugins/etunel-role-collaboration/.codex-plugin/plugin.json
+1 -1
View File
@@ -1,6 +1,6 @@
{ {
"name": "etunel-role-collaboration", "name": "etunel-role-collaboration",
"version": "2.0.0", "version": "2.1.0",
"description": "EP Hub 项目中心：按八阶段管理交付任务、真人确认、项目进度、信息交接和成果留档。", "description": "EP Hub 项目中心：按八阶段管理交付任务、真人确认、项目进度、信息交接和成果留档。",
"author": { "author": {
"name": "chenmingxuan", "name": "chenmingxuan",
plugins/codex/plugins/etunel-role-collaboration/THIRD_PARTY_SOURCE.json
+3 -3
View File
@@ -1,9 +1,9 @@
{ {
"sourceId": "etunel-role-collaboration", "sourceId": "etunel-role-collaboration",
"repo": "https://git.playones.com/chenmingxuan/EP-Hub-Skill.git", "repo": "https://git.playones.com/chenmingxuan/EP-Hub-Skill.git",
"ref": "v2.0.0", "ref": "v2.1.0",
"commit": "98541d682bf2ff4b4127eee19eeb76a3b66ada47", "commit": "075837d51f5816ad42154f84683ff6b5605654fc",
"adapter": "claude-skill", "adapter": "claude-skill",
"sourcePath": "ep-hub", "sourcePath": "ep-hub",
"syncedAt": "2026-10-12T04:59:58Z" "syncedAt": "2026-10-21T06:48:34Z"
} }
plugins/codex/plugins/etunel-role-collaboration/skills/ep-hub/SKILL.md
+7 -5
View File
@@ -11,8 +11,8 @@ description: 作为项目中心，按八阶段管理交付任务、真人确认
- 按可独立确认的交付结果管理任务；同一负责人承担的内聚工作可组成任务包。每项任务有一名主责真人、明确输入、范围、结果、期限与完成条件，不拆成中心监督的内部步骤。 - 按可独立确认的交付结果管理任务；同一负责人承担的内聚工作可组成任务包。每项任务有一名主责真人、明确输入、范围、结果、期限与完成条件，不拆成中心监督的内部步骤。
- 真人可以直接协作，任务接收与结果提交可以在线下完成；必须保留实际接收、提交和确认的依据。成员 Agent 之间的信息仍经中心定向中继。 - 真人可以直接协作，任务接收与结果提交可以在线下完成；必须保留实际接收、提交和确认的依据。成员 Agent 之间的信息仍经中心定向中继。
- 同一阶段内，任务确认完成后可启动依赖已经满足的后续任务；跨阶段推进须取得中心真人明确决定。中心决定不能替代专业判断、业务授权、产品资源排期确认或外部验收。 - 同一阶段内，任务确认完成后可启动依赖已经满足的后续任务；跨阶段须有中心真人明确决定，已有条件授权实际满足后按原范围执行并记录依据，不重复申请。中心决定不能替代专业判断、业务授权、产品授权范围内的资源排期确认或外部验收。
- 正式成果只保存真人完成并确认的最终有效版本及确认记录；草稿、旧版、历史确认和中心推进决定进入过程记录。链接交付只记录地址，不要求复制、截图或重新下载。 - 正式成果保存真人完成并确认的全部有效成果、配套资料或完整外部入口及确认；草稿、旧版、历史确认和中心推进决定进入过程记录。链接交付不强制下载、截图或复制；本地复制按项目明确授权处理。
- 实际完成时间是任务提交后，经对应真人明确确认完成的时间。提交、送达、已读、Agent 检查或工具任务完成都不能替代这一确认。 - 实际完成时间是任务提交后，经对应真人明确确认完成的时间。提交、送达、已读、Agent 检查或工具任务完成都不能替代这一确认。
- 项目层持续显示当前阶段、整体进度、当前待处理事项，以及未完成事项的原计划、当前计划、影响范围和必须完成的阶段；跨阶段沿用原任务记录。 - 项目层持续显示当前阶段、整体进度、当前待处理事项，以及未完成事项的原计划、当前计划、影响范围和必须完成的阶段；跨阶段沿用原任务记录。
- 不重复要求已有有效确认；成果或版本发生实质变化、适用范围扩大或出现相反证据时，仅重新确认受影响部分。 - 不重复要求已有有效确认；成果或版本发生实质变化、适用范围扩大或出现相反证据时，仅重新确认受影响部分。
@@ -23,14 +23,16 @@ description: 作为项目中心，按八阶段管理交付任务、真人确认
| 要做什么 | 读取什么 | | 要做什么 | 读取什么 |
| --- | --- | | --- | --- |
| 接收请求、组织交付任务、收取结果或交接阶段 | [中心工作流](references/hub-workflow.md) | | 接收请求、组织交付任务、收取结果或交接阶段 | [中心工作流](references/hub-workflow.md) |
| 向中心真人汇报阶段结果、请求推进或执行条件授权 | [阶段汇报与推进决定](references/stage-reporting.md) |
| 判断阶段、应交成果和推进条件 | [八阶段与结果要求](references/project-lifecycle.md)，只读当前阶段及受影响阶段 | | 判断阶段、应交成果和推进条件 | [八阶段与结果要求](references/project-lifecycle.md)，只读当前阶段及受影响阶段 |
| 建立目录、更新任务、阶段和项目进度 | [记录与留档](references/project-records.md)，其中链接五类 Markdown 模板 | | 评估工时、衔接周期、编排或更新计划主表 | [工时、周期与项目计划](references/project-planning.md) |
| 建立目录、更新任务、阶段和项目进度 | [记录与留档](references/project-records.md)，按需使用其中的记录模板 |
| 判断成果、真人确认、版本替换或完成时间 | [成果与确认](references/artifacts-and-confirmation.md) | | 判断成果、真人确认、版本替换或完成时间 | [成果与确认](references/artifacts-and-confirmation.md) |
| 处理延期、阻塞、变更、退回、豁免或放行 | [异常与决定](references/exceptions-and-decisions.md) | | 处理延期、阻塞、变更、退回、豁免、放行或 Bug 双方确认 | [异常与决定](references/exceptions-and-decisions.md) |
| 配置中心与成员、使用 Etunel 或排障 | [Etunel 分工](references/etunel-boundary.md)，再使用已安装的 etunel-use 对应参考 | | 配置中心与成员、使用 Etunel 或排障 | [Etunel 分工](references/etunel-boundary.md)，再使用已安装的 etunel-use 对应参考 |
| 选择旧模板、历史样例或外部成果格式 | [模板复用](references/document-templates.md) | | 选择旧模板、历史样例或外部成果格式 | [模板复用](references/document-templates.md) |
| 编写或发送钉钉项目通知、提醒真人 | [通知规则与消息模板](references/dingtalk-progress-reporting.md)；实际调用时再读其脚本用法 | | 编写或发送钉钉项目通知、提醒真人 | [通知规则与消息模板](references/dingtalk-progress-reporting.md)；实际调用时再读其脚本用法 |
## 本轮输出 ## 本轮输出
用简洁中文逐条说明已确认进展、需要处理或决定的事项、遗留及影响。先更新事实记录，再依据授权交接、推进或通知。未知的负责人、时间、确认与影响如实标明，不能为补齐格式编造事实，也不把一次问答变成新的交付文件。 用简洁中文逐条说明已确认进展、需要处理或决定的事项、遗留及影响。先更新事实记录，再主动在中心会话汇报阶段结果；只更新文件不算汇报。需要真人查看时逐项提供本次全部有效成果入口。再依据授权交接、推进或通知。未知的负责人、时间、确认与影响如实标明，不能为补齐格式编造事实，也不把一次问答变成新的交付文件。
plugins/codex/plugins/etunel-role-collaboration/skills/ep-hub/assets/templates/任务记录.md
+4 -1
View File
@@ -25,10 +25,13 @@
## 成果与确认 ## 成果与确认
- **接收情况**：记录真人实际接收时间及依据；只有发送证据时标为接收待确认。 - **接收情况**：记录真人实际接收时间及依据；只有发送证据时标为接收待确认。
- **提交情况**：每次提交单列提交人、时间、成果版本和保存位置。 - **提交情况**：每次提交单列提交人、时间、成果版本和完整入口、用途；本人说明其他渠道已提交时据实登记，入口缺失、接收待确认与验收待确认分别列出。
- **完成情况**：说明已完成、未完成部分及具体缺口。 - **完成情况**：说明已完成、未完成部分及具体缺口。
- **确认情况**：每项单列确认人、真实确认时间、任务／成果及版本、结论、范围和条件。 - **确认情况**：每项单列确认人、真实确认时间、任务／成果及版本、结论、范围和条件。
- **确认来源**：记录直接确认或线下转述；转述保留实际确认人、转述人、来源及补录时间。 - **确认来源**：记录直接确认或线下转述；转述保留实际确认人、转述人、来源及补录时间。
- **采用与存放调整**：适用时分别记录采用对象和日期、本地复制授权、原路径到正式路径映射及操作日期，不覆盖原提交或确认日期。
需要评估时在此嵌入 [工时与周期栏目](工时与周期评估.md)；涉及 Bug 时沿原问题／共用记录保留中心先确认、产品再次确认的 [字段与历史](../../references/exceptions-and-decisions.md#bug-处理与双方最终确认)。生成实际项目记录时仅保留适用内容和真实入口，不将模板链接当项目事实。
## 下一步与影响 ## 下一步与影响
plugins/codex/plugins/etunel-role-collaboration/skills/ep-hub/assets/templates/工时与周期评估.md
+35
View File
@@ -0,0 +1,35 @@
# 工时与周期评估栏目
> 使用指引：仅在需要评估时嵌入原任务记录；按真实工作项展开，不另建一套任务。先列已交接的全部有效需求文件和版本入口。各角色内部执行方法自行决定。
## 工作范围
- **主责真人／角色**：填写已确认分工。
- **需求输入**：逐项列全部有效文件、版本和入口。
- **已有成果与剩余工作**：分别说明。
- **未估项**：说明缺什么信息及受影响部分；不能把未知填零。
## 工作项评估
| 工作项／初版或轮次 | 主责真人 | 原估值及单位 | 当前估值及单位 | 周期及起算条件 |
| --- | --- | --- | --- | --- |
| 按真实工作项填写 | 按实际分工填写 | 保留首次评估 | 保留有效评估 | 周期与人时分开 |
### 对应工作项的条件与依据
- **投入与人数**：记录可投入情况及资源是否已确认。
- **外部等待**：单列条件、等待周期及来源。
- **提交**：实际提交人、时间、版本及入口。
- **确认**：确认人、时间、对象、结论、适用范围及来源。
- **当前状态**：区分已估、待补充、待确认及已确认。
- **评估变更**：保留旧值、新值、原因和真人确认，关联原任务关键历史。
初版单列，后续迭代不包含初版。开发／自测／修复、独立测试／回归和外部等待分别记录。工作日不直接换算成人日或小时。
## 技术核实与测试衔接
- **技术核实**：记录技术负责人、真实日期、核实的对象及版本、范围／依赖和结论，引用原任务已有有效确认。
- **交给测试**：记录实际交接日期、版本、范围及渠道。
- **测试接收与衔接**：记录实际接收人、时间和依据，以及初版、各轮、回归的周期与资源衔接结论；未知部分标明待确认。
沿用已有确认和接收记录，仅补实际缺口，不为此重批评估或另建交接文件。
plugins/codex/plugins/etunel-role-collaboration/skills/ep-hub/assets/templates/成果索引.md
+2 -1
View File
@@ -7,5 +7,6 @@
### 成果名称 ### 成果名称
- **当前最终版本**：记录实际有效版本。 - **当前最终版本**：记录实际有效版本。
- **位置或链接**：只填写实际文件或链接地址，不复制外部内容。 - **位置与用途**：逐项登记全部有效原件／包、配套资料或真实完整外部入口与用途；包内容可引用有效索引，不强制复制外部内容。
- **确认记录**：链接对应阶段的正式确认栏目，确认详情由那里统一维护。 - **确认记录**：链接对应阶段的正式确认栏目，确认详情由那里统一维护。
- **存放调整**：适用时关联本地复制授权、原位置与正式位置映射、操作日期；不改原提交、采用或确认时间。
plugins/codex/plugins/etunel-role-collaboration/skills/ep-hub/assets/templates/结项资料归档.md
+32
View File
@@ -0,0 +1,32 @@
# 结项资料归档
> 使用指引：作为既有《结项资料归档》的内容结构，沿用项目已确认格式，不新增第五类结项成果。以下说明替换为真实资料与依据。
## 归档范围
- **项目与范围**：明确实际采用的版本和本次整理范围。
- **当前成果索引**：关联项目唯一成果索引。
## 各阶段有效资料
### 阶段名称
- **管理开始日期与依据**：中心真人实际启用；条件授权时记录实际切换。
- **管理完成日期与依据**：明确结束／下一阶段决定；条件授权交接取实际切换日期，阶段八为关闭日期，进行中留空。
- **工程实际日期**：按实际需要分别记录开发、测试和验收日期及来源。
#### 成果名称
- **有效版本与用途**：列每项成果、配套资料及包内容；一包多成果可引用有效内容索引。
- **完整入口**：已保存原件／包的实际路径，或真实完整外部地址；不能只列概括目录。
- **提交与采用**：分别记录真人、日期、对象、范围及依据。
- **最终确认**：记录确认人、真实日期、对象版本、结论、范围与条件。
- **原任务及过程记录**：关联原任务、旧版和历史确认。
- **本地复制或地址调整**：适用时记录授权、原路径与现路径映射、操作日期；不得覆盖原提交、采用、确认或完成时间。
## 关闭及承接
- **Bug 处理与承接**：引用原报告／共用记录中的中心和产品双方最终确认，保留未修复事实与后续责任。
- **其他遗留**：逐项列状态、责任、原计划、当前计划、影响及必须完成阶段。
- **业务结项确认与中心关闭决定**：分别列真人、日期、原话、范围、条件和依据。
- **关闭后登记**：记录概览、进度、阶段、原任务、索引、报告与汇总的同步情况，以及有效成果锁定和停止重复催办情况。
plugins/codex/plugins/etunel-role-collaboration/skills/ep-hub/assets/templates/阶段成果汇报.md
+33
View File
@@ -0,0 +1,33 @@
# 阶段成果汇报
> 使用指引：可直接作为中心聊天的汇报结构；也可写入阶段过程记录。不新增正式成果要求。将以下说明替换为真实事实。
## 当前阶段
- **项目与汇报日期**：记录项目名称和本次真实汇报日期。
- **阶段与状态**：记录阶段编号、名称、当前情况及管理开始／完成日期；进行中完成日期留空。
- **本轮需要决定**：说明推进、补充、退回、暂缓或承接的具体事项。
## 逐项任务与成果
### 任务名称
- **主责真人与完成情况**：记录实际负责人、完成部分和未完成部分。
- **应交成果**：逐项列必需／选填及适用条件。
- **已交成果**：每份单列名称、版本、确认用途和完整可点击入口；同一成果包可引用有效内容索引。
- **确认情况**：逐项列确认人、真实时间、对象、结论、范围、条件和来源；缺失确认单列。
- **时间**：分别列原计划、当前计划、提交时间和提交后真人确认的实际完成时间。
- **原任务记录**：引用唯一原记录。
## 未完成与待确认
- **事项**：每项单列状态、原因、依赖、主责、原计划、当前计划、影响及必须完成阶段。
- **需要的决定**：列已有安排、建议和待决定内容，分别标明。
确实没有时写“未完成项：无；待确认项：无”。资料不足时说明待核实部分。
## 下一步安排
- **建议**：按当前事实提出下一步。
- **已有决定或条件授权**：记录真人、原话、日期、范围与条件；条件满足及实际切换日期另记。
- **仍待决定**：列需要谁确认什么，以及确认后的动作。
plugins/codex/plugins/etunel-role-collaboration/skills/ep-hub/assets/templates/阶段记录.md
+20 -2
View File
@@ -3,7 +3,9 @@
> 填写指引：标题改为阶段编号与名称，紧接一句当前情况。下面两个栏目分别保存最终成果和任务过程；每个任务都要逐项汇总。 > 填写指引：标题改为阶段编号与名称，紧接一句当前情况。下面两个栏目分别保存最终成果和任务过程；每个任务都要逐项汇总。
- **阶段状态**：记录未开始、进行中、待确认、已完成或实际例外状态。 - **阶段状态**：记录未开始、进行中、待确认、已完成或实际例外状态。
- **阶段时间**：记录已约定计划、实际进入与阶段决定时间。 - **管理开始日期与依据**：中心真人实际启用日期；条件授权时取实际切换日期。
- **管理完成日期与依据**：明确结束或进入下一阶段的决定日期；条件授权交接取实际切换日期，阶段八取明确关闭日期，进行中留空。
- **工程实际日期**：按实际需要另记开发、测试和验收日期，不以管理日期计算工程延期或人时。
- **当前情况**：概括本阶段完成到哪里。 - **当前情况**：概括本阶段完成到哪里。
## 正式成果及确认记录 ## 正式成果及确认记录
@@ -12,7 +14,8 @@
- **成果名称**：每项最终成果独立列出。 - **成果名称**：每项最终成果独立列出。
- **最终版本**：记录真人完成并确认的当前有效版本。 - **最终版本**：记录真人完成并确认的当前有效版本。
- **保存位置**：使用实际文件位置或外部链接。 - **保存位置与用途**：逐项给全部有效文件、配套资料或包内有效索引的完整实际入口及用途；不能只列总目录。
- **提交与采用**：分别记录实际日期、对象和来源；复制或补地址日期另记。
### 对应真人确认 ### 对应真人确认
@@ -33,6 +36,7 @@
- **确认情况**：列已确认人、时间、对象、结论和未完成的必要确认。 - **确认情况**：列已确认人、时间、对象、结论和未完成的必要确认。
- **原计划完成时间**：记录首次期限。 - **原计划完成时间**：记录首次期限。
- **当前计划完成时间**：记录最新有效期限。 - **当前计划完成时间**：记录最新有效期限。
- **实际提交时间**：记录本人提交事实与来源；线下已交但入口缺失时分别说明。
- **实际完成时间**：任务提交后经真人明确确认完成的时间；未确认写“尚未确认完成”。 - **实际完成时间**：任务提交后经真人明确确认完成的时间；未确认写“尚未确认完成”。
- **影响及下一步**：列责任、动作、必须完成的阶段及跨阶段承接。 - **影响及下一步**：列责任、动作、必须完成的阶段及跨阶段承接。
- **任务原记录**：链接该任务的唯一记录。 - **任务原记录**：链接该任务的唯一记录。
@@ -40,5 +44,19 @@
### 阶段决定与未完成事项 ### 阶段决定与未完成事项
- **决定**：每次单列决定人、时间、推进／补充／退回／暂缓结论、依据、范围和理由。 - **决定**：每次单列决定人、时间、推进／补充／退回／暂缓结论、依据、范围和理由。
- **条件授权**：适用时分别记原授权日期、原话、条件、条件实际满足日期与依据、实际切换日期；不倒填已推进。
- **未完成事项**：逐项引用原任务，列原计划、当前计划、必须完成阶段、影响、承接与阶段结束提醒情况。 - **未完成事项**：逐项引用原任务，列原计划、当前计划、必须完成阶段、影响、承接与阶段结束提醒情况。
- **历史资料**：链接旧版、草稿、历史确认及替代关系。 - **历史资料**：链接旧版、草稿、历史确认及替代关系。
### 汇报与通知
- **中心会话汇报**：记录本次汇报时间、涉及任务与成果、未完成／待确认事项及待决定内容。
- **群总结**：记录对应交接或关闭决定、已发送正文及实际结果；区分未发送、请求已接受、送达和已读，只写有依据的状态。
- **补充汇报**：仅实质变化时补充受影响内容；核对前次记录避免重复通知同一次交接。
### 关闭后登记（阶段八适用）
- **Bug 双方确认**：引用原问题或共用记录中的最终确认与分歧历史。
- **关闭决定**：记录中心真人、真实日期、原话、范围和条件，业务结项确认另列。
- **同步与锁定**：记录项目概览、进度、原任务、索引、报告和汇总同步情况，以及有效成果锁定情况。
- **停止催办与后续**：停止已结束／已确认事项的重复催办；未完成承接和队列未送达分别记录。
plugins/codex/plugins/etunel-role-collaboration/skills/ep-hub/assets/templates/项目概览.md
+6
View File
@@ -18,6 +18,12 @@
## 资料与协作入口 ## 资料与协作入口
- **项目进度**：链接实际进度记录。 - **项目进度**：链接实际进度记录。
- **唯一计划主表**：链接已确认使用的实际主表；已有项目沿用，新项目默认使用 Excel。
- **成果索引**：链接当前有效成果索引。 - **成果索引**：链接当前有效成果索引。
- **资料来源**：列已提供的项目资料位置。 - **资料来源**：列已提供的项目资料位置。
- **交接方式**：说明已确认的通信渠道、接收与提交方式。 - **交接方式**：说明已确认的通信渠道、接收与提交方式。
## 项目关闭
- **关闭决定**：实际关闭后记录中心真人、日期、原话、范围、条件及依据；未关闭时不预填。
- **承接入口**：链接仍需跟进的原任务及当前进度，保留未完成状态。
plugins/codex/plugins/etunel-role-collaboration/skills/ep-hub/assets/templates/项目计划.xlsx
BIN
View File
Binary file not shown.
plugins/codex/plugins/etunel-role-collaboration/skills/ep-hub/assets/templates/项目进度.md
+6
View File
@@ -6,6 +6,7 @@
- **更新时间**：记录本次更新的时间。 - **更新时间**：记录本次更新的时间。
- **当前阶段**：记录有效阶段编号、名称及推进依据。 - **当前阶段**：记录有效阶段编号、名称及推进依据。
- **唯一计划主表**：引用实际主表，本记录只维护阶段及当前事项摘要。
- **已完成阶段**：逐项列出，跳过或暂缓的单独说明。 - **已完成阶段**：逐项列出，跳过或暂缓的单独说明。
- **关键成果**：说明已经完成、待确认和缺失的关键结果。 - **关键成果**：说明已经完成、待确认和缺失的关键结果。
- **下一步**：说明待推进的工作及必要条件。 - **下一步**：说明待推进的工作及必要条件。
@@ -28,3 +29,8 @@
## 已完成或已处置 ## 已完成或已处置
- **事项**：每项单列完成或处置结论、真人及时间、原记录入口；仍有后续跟进的继续保留在当前事项中。 - **事项**：每项单列完成或处置结论、真人及时间、原记录入口；仍有后续跟进的继续保留在当前事项中。
## 关闭决定与后续
- **决定依据**：实际关闭后引用中心真人、真实日期、原话、范围及条件。
- **承接事项**：沿原责任与计划在当前事项中持续跟进，不把关闭写成全部 Bug 已修复或测试通过。
plugins/codex/plugins/etunel-role-collaboration/skills/ep-hub/references/artifacts-and-confirmation.md
+14 -2
View File
@@ -14,6 +14,16 @@
中心真人可在会话中明确转述线下接收、提交或确认事实。保留实际确认人、真实确认时间、对象、结论和范围，并注明转述人、来源及补录时间；缺失信息写待补充。不要求另做审批单、截图或重复确认，不能把转述者写成专业确认人。 中心真人可在会话中明确转述线下接收、提交或确认事实。保留实际确认人、真实确认时间、对象、结论和范围，并注明转述人、来源及补录时间；缺失信息写待补充。不要求另做审批单、截图或重复确认，不能把转述者写成专业确认人。
本人明确已通过其他渠道提交时，登记已提交。资料入口未提供、接收人尚未确认可用、验收尚未取得结论是不同缺口，逐项记录；无聊天附件、Agent 本端无法读取或队列仍待投递不推翻线下提交事实。
## 供真人查看的成果
请求中心真人确认前，逐项列出本次范围内全部有效文件的名称、版本、确认用途和完整可点击地址，或直接展示文件。成果包可使用能逐项定位内容的有效索引；只给概括目录、摘要或中心确认记录不足以支持查看。
专业内容和接收可用性由相应真人判断。Agent 无法读取本地盘、共享盘或外部链接，只能说明本端访问失败，不能推定成果不存在、未提交或不兼容。不把下载、解包、截图、重算哈希设成固定前置条件。已有包身份和真实入口时交相关真人确认可用，仅补实际缺口，不要求重做或反复上传。
文件、需求或版本存在差异时，由有权真人决定采用的内容、对象、版本和范围。分别记录当前同步情况、历史实际审阅对象及差异对原结论的影响；不能补造历史审阅或把当前采用倒填为过去已审阅。
## 实际完成时间 ## 实际完成时间
**任务提交后，经对应真人明确确认该任务完成的时间，才是实际完成时间。** **任务提交后，经对应真人明确确认该任务完成的时间，才是实际完成时间。**
@@ -27,11 +37,13 @@
## 正式成果与历史 ## 正式成果与历史
- 正式区只保存真人完成并确认的最终成果，每项一个当前有效版本。登记名称、版本、文件位置或链接；确认另列确认人、时间、对象及版本、结论、范围和条件。 - 正式区保存真人完成并确认的全部有效成果和配套资料，每项一个当前有效版本。保存原件／包，或登记真实完整外部入口；确认另列确认人、时间、对象及版本、结论、范围和条件。概括目录或确认记录不能代替资料本身。
- 待确认稿、部分成果、候选固件、旧版及其历史确认进入过程区。任务记录关联所有提交，阶段正式栏目只列最终成果。 - 待确认稿、部分成果、候选固件、旧版及其历史确认进入过程区。任务记录关联所有提交，阶段正式栏目只列最终成果。
- 新版获真人确认后才替换当前条目；先保留旧文件、旧确认及替代关系到过程区，再更新正式记录，不能覆盖丢失历史。外部链接成果保留旧地址、版本、确认及替代关系；不额外下载快照，外部系统是否保留历史如实记录。 - 新版获真人确认后才替换当前条目；先保留旧文件、旧确认及替代关系到过程区，再更新正式记录，不能覆盖丢失历史。外部链接成果保留旧地址、版本、确认及替代关系；不额外下载快照，外部系统是否保留历史如实记录。
- 中心推进、豁免、版本放行、产品接收等事实放过程记录，引用相关正式成果。名为《变更记录》《流程闭环总结》的交付文档，在真人确认最终版后仍属于正式成果。 - 中心推进、豁免、版本放行、产品接收等事实放过程记录，引用相关正式成果。名为《变更记录》《流程闭环总结》的交付文档，在真人确认最终版后仍属于正式成果。
- 链接交付只记地址与确认；内容核实由真人负责，不把复制内容、摘要、截图或可下载检查变成中心必做事项。 - 同一文件或连贯成果包可承载多个结果，不为凑名称拆造文件。名称含“草稿／预览”不自动否定真人已确认采用的正式地位；按实际确认判断，不为分区删改成果正文。
- 链接交付登记真实地址、用途、版本与确认；内容核实由真人负责，不强制复制、摘要、截图或可下载检查。项目明确授权本地复制时，把已取得且确认有效的原件和配套资料复制到对应阶段正式区，保留原交接记录及原路径到现路径的映射，更新索引到正式位置。
- 复制或补地址日期单独记录，不替换提交、采用、确认、实际完成或阶段日期；未取得的原件仍如实列缺口，不能写已归档。
- 实质变更、范围扩大或相反证据需要重新确认受影响部分；仅改存放位置、阶段引用或转述补录不自动触发重签。 - 实质变更、范围扩大或相反证据需要重新确认受影响部分；仅改存放位置、阶段引用或转述补录不自动触发重签。
测试“不通过”可被真人确认是实际测试结论，不能因版本获放行改成“通过”。测试结果确认、版本放行、阶段推进与外部验收分别保留。 测试“不通过”可被真人确认是实际测试结论，不能因版本获放行改成“通过”。测试结果确认、版本放行、阶段推进与外部验收分别保留。
plugins/codex/plugins/etunel-role-collaboration/skills/ep-hub/references/dingtalk-progress-reporting.md
+39 -3
View File
@@ -18,6 +18,14 @@
Hub 必须先核对真实事实，更新对应任务、阶段和项目进度记录；涉及正式成果变化时再更新成果与索引，然后发送钉钉消息。不为一次通知新增成果文件。钉钉发送失败不回滚留档，也不阻塞项目主任务。 Hub 必须先核对真实事实，更新对应任务、阶段和项目进度记录；涉及正式成果变化时再更新成果与索引，然后发送钉钉消息。不为一次通知新增成果文件。钉钉发送失败不回滚留档，也不阻塞项目主任务。
## 阶段交接与结项总结
- 每次中心真人批准推进，或已有条件授权实际满足并已执行交接后，在已启用且获授权的通知范围内，将上一阶段总结与下一阶段安排合为一条 `milestone`。标题使用实际当前阶段。
- 等待推进决定时，先在中心会话按 [阶段汇报规则](stage-reporting.md) 说明成果、未完成项及待决定事项，不发宣称已进入下一阶段的总结；已授权的实质进展或阻塞通知仍可按实际事件发送。
- 正文仍用“已确认的进展／待办事项／遗留”：进展写上一阶段成果和真实推进决定；待办写下一阶段全部已确认任务、主责和期限，未知字段如实说明；遗留写未完成及待确认、影响和承接。完整成果汇报放中心会话，群里可引用适合接收者访问的有效记录入口，不能为缩短篇幅遗漏待办或停止事项。
- 第八阶段取得明确关闭决定后发送一次 `complete` 结项总结，列有效成果、关闭决定及承接事项的主责和计划。后续资料整理、补地址不重复发关闭通知。
- 将总结正文、对应决定和实际发送结果记入阶段过程记录；生成前核对是否已通知同一次交接或关闭。复用原记录，不增加通知队列或脚本外重试。API 接受、投递和已读分别记录，未知结果不盲目重发。
## 事件判定 ## 事件判定
### start ### start
@@ -34,7 +42,7 @@ Hub 必须先核对真实事实，更新对应任务、阶段和项目进度记
- 正式阻塞解除，项目恢复到明确下一动作； - 正式阻塞解除，项目恢复到明确下一动作；
- 统一固件、版本矩阵、测试结论、验收或发布组合形成。 - 统一固件、版本矩阵、测试结论、验收或发布组合形成。
同一处理轮或同一波次合并成一条，不逐个小任务刷屏。没有固定时间间隔；依靠事件语义和去重控制频率。 保留已授权范围内的阶段关键进展通知；同一处理轮或同一波次合并成一条，不逐个小任务刷屏。同轮发生阶段交接时合入交接总结，核对阶段过程记录避免重复。没有固定时间间隔。
### blocked ### blocked
@@ -48,7 +56,7 @@ Hub 必须先核对真实事实，更新对应任务、阶段和项目进度记
### complete ### complete
整个项目或用户明确指定的整体目标最终完成时发送一次。模拟项目必须明确写“模拟完成”，不得表达真实发布、客户验收或生产就绪。 项目生命周期中，阶段八满足必要条件、业务已确认结项且中心真人明确关闭后发送一次。开始结项整理不使用 `complete`。用户明确指定的独立整体目标最终完成时，限定在该目标范围表述，不能冒充项目关闭。模拟项目必须明确写“模拟完成”，不得表达真实发布、客户验收或生产就绪。
### failed ### failed
@@ -85,7 +93,9 @@ Hub 必须先核对真实事实，更新对应任务、阶段和项目进度记
- 结项资料整理：由中心真人负责人组织四类结项成果，Hub 协助整理工作稿。 - 结项资料整理：由中心真人负责人组织四类结项成果，Hub 协助整理工作稿。
- 资料补充：由产品负责人、业务负责人补充现有线下成果及确认记录，不重做验收。 - 资料补充：由产品负责人、业务负责人补充现有线下成果及确认记录，不重做验收。
- 旧事项停止：由 Hub 停止此前的验收准备催办。 - 旧事项停止：由 Hub 停止此前的验收准备催办。
- 结项确认：四类成果及遗留承接安排具备后，由 Hub 请 @示例业务负责人 确认结项。 - Bug 事实确认：由 Hub 请 @示例中心负责人 先确认全部 Bug 的对象、版本和实际处理或承接，已有有效确认直接引用。
- Bug 处理确认：中心确认事实后，由 Hub 请 @示例产品负责人 再次确认，并在职责内决定处理方式；双方无异议后记录最终安排。
- 结项确认：四类成果、遗留承接及 Bug 双方确认具备后，由 Hub 请 @示例业务负责人 确认结项。
- 关闭决定：业务确认结项后，由 Hub 请 @示例中心负责人 决定是否关闭；结项必需项完成后锁定四类成果。 - 关闭决定：业务确认结项后，由 Hub 请 @示例中心负责人 决定是否关闭；结项必需项完成后锁定四类成果。
- 本轮工作范围：不新增应用修复、设备测试或发布验证。 - 本轮工作范围：不新增应用修复、设备测试或发布验证。
@@ -97,6 +107,32 @@ Hub 必须先核对真实事实，更新对应任务、阶段和项目进度记
示例标题、时间和栏目只说明最终呈现方式；调用时正文文件仅含正文，项目名、阶段标题与时间由脚本生成，不重复粘贴整条通知。 示例标题、时间和栏目只说明最终呈现方式；调用时正文文件仅含正文，项目名、阶段标题与时间由脚本生成，不重复粘贴整条通知。
### 已关闭项目的结项总结示例
以下仅说明格式。事实、决定人、日期、有效成果入口、后续主责和期限都须替换为项目真实记录，不把此例当成关闭依据。
```markdown
**示例项目｜阶段八：复盘结项**
项目进度自动汇报 · 发送时自动生成带时区的时间
**已确认的进展**
- 四类结项成果已取得必要确认，有效文件和入口已登记在项目成果索引。
- 全部 Bug 的处理或承接已由中心先确认、产品再次确认，双方无异议。
- 业务已确认结项，中心真人已明确关闭项目；决定的日期、范围和条件已记录。
- 已同步相关记录、锁定有效成果，停止已结束阶段的重复催办。
**待办事项**
- 遗留跟进：请 @示例处理人 按原问题记录中的当前计划继续处理已承接事项，原计划和变更历史保留。
**遗留**
- 已接受延期的 Bug 尚未修复，责任、原计划、当前计划和影响沿用原记录；项目关闭不代表问题已修复。
- 原测试不通过结论保留，版本放行、验收和关闭决定分别记录。
```
保留个人消息的 AI 标识和自动汇报说明，让群成员知道这是 Hub 自动通知，不是负责人本人新增批准、验收或承诺。 保留个人消息的 AI 标识和自动汇报说明，让群成员知道这是 Hub 自动通知，不是负责人本人新增批准、验收或承诺。
根据事件选择必要内容：已验证进展、关键成果、下一步和责任角色；阻塞时再说明问题、影响以及需要谁采取什么动作。尽量简短，但不能为了控制篇幅省掉本轮需要决定或处理的事项。专业细节留在成果或问题系统中，通知不新建另一份问题台账。 根据事件选择必要内容：已验证进展、关键成果、下一步和责任角色；阻塞时再说明问题、影响以及需要谁采取什么动作。尽量简短，但不能为了控制篇幅省掉本轮需要决定或处理的事项。专业细节留在成果或问题系统中，通知不新建另一份问题台账。
plugins/codex/plugins/etunel-role-collaboration/skills/ep-hub/references/dingtalk-script-usage.md
+17 -2
View File
@@ -39,14 +39,16 @@ python scripts/dingtalk_notify.py progress milestone --stage "阶段八：复盘
- 结项资料整理：由中心真人负责人组织四类结项成果，Hub 协助整理工作稿。 - 结项资料整理：由中心真人负责人组织四类结项成果，Hub 协助整理工作稿。
- 资料补充：由产品负责人、业务负责人补充现有线下成果及确认记录，不重做验收。 - 资料补充：由产品负责人、业务负责人补充现有线下成果及确认记录，不重做验收。
- 旧事项停止：由 Hub 停止此前的验收准备催办。 - 旧事项停止：由 Hub 停止此前的验收准备催办。
- 结项确认：四类成果及遗留承接安排具备后，由 Hub 请 @{示例业务负责人} 确认结项。 - Bug 事实确认：由 Hub 请 @{示例中心负责人} 先确认全部 Bug 的事实、对象、版本和实际处理或承接，已有有效确认直接引用。
- Bug 处理确认：中心确认事实后，由 Hub 请 @{示例产品负责人} 再次确认并在职责内决定处理；双方无异议后登记最终安排。
- 结项确认：四类成果、遗留承接及 Bug 双方确认具备后，由 Hub 请 @{示例业务负责人} 确认结项。
- 关闭决定：业务确认结项后，由 Hub 请 @{示例中心负责人} 决定是否关闭；结项必需项完成后锁定四类成果。 - 关闭决定：业务确认结项后，由 Hub 请 @{示例中心负责人} 决定是否关闭；结项必需项完成后锁定四类成果。
- 本轮工作范围：不新增应用修复、设备测试或发布验证。 - 本轮工作范围：不新增应用修复、设备测试或发布验证。
**遗留** **遗留**
- 原测试不通过的结果如实保留，不因进入结项阶段改为通过。 - 原测试不通过的结果如实保留，不因进入结项阶段改为通过。
- 已接受延期的问题如实保留，后续沿用 Bug 系统中的记录和已有处理安排继续跟进。" --at "示例业务负责人" --at "示例中心负责人" - 已接受延期的问题如实保留，后续沿用 Bug 系统中的记录和已有处理安排继续跟进。" --at "示例业务负责人" --at "示例中心负责人" --at "示例产品负责人"
python scripts/dingtalk_notify.py progress blocked --stage "阶段三：方案设计" "**已确认的进展** python scripts/dingtalk_notify.py progress blocked --stage "阶段三：方案设计" "**已确认的进展**
- 本轮无新增已确认进展。 - 本轮无新增已确认进展。
@@ -75,6 +77,19 @@ python scripts/dingtalk_notify.py message --title "阶段三：方案设计｜
- 脚本只接受唯一姓名匹配，自动构造个人消息所需的 `openDingTalkId` 和提及标记。查不到、重名或权限不足时停止，不让负责人手填编号，不删掉 @ 降级发送。 - 脚本只接受唯一姓名匹配，自动构造个人消息所需的 `openDingTalkId` 和提及标记。查不到、重名或权限不足时停止，不让负责人手填编号，不删掉 @ 降级发送。
- 默认且仅发配置的项目群。同一事项合成一条，事件通知可直接 @ 人，不额外重复提醒。提醒讨论结果通过已约定渠道返回并留档，不在群里另派任务或批准。 - 默认且仅发配置的项目群。同一事项合成一条，事件通知可直接 @ 人，不额外重复提醒。提醒讨论结果通过已约定渠道返回并留档，不在群里另派任务或批准。
## 阶段交接和关闭通知
中心真人已批准推进或条件授权实际满足后，将上一阶段总结与下一阶段已确认安排合为一条 `milestone`。阶段内已授权的关键进展、阻塞、失败通知保留，同轮合并。等待决定时先在中心会话汇报，不宣称已进入下一阶段。
项目实际关闭后，用 `complete` 发送一次结项总结，保留未修复 Bug、失败测试和已确认承接；后续整理资料不重复发送。完整示例见 [通知规则](dingtalk-progress-reporting.md)。较长正文可保存为 UTF-8 文件，先离线预览：
```text
python scripts/dingtalk_notify.py progress milestone --stage "实际当前阶段" --file "阶段交接正文.md" --at "已确认完整姓名" --dry-run
python scripts/dingtalk_notify.py progress complete --stage "阶段八：复盘结项" --file "结项总结正文.md" --at "已确认完整姓名" --dry-run
```
正文文件和姓名须替换为实际值，正文无真人提醒时省略 `--at`。通知范围已授权且本次满足触发条件后，真实调用去掉 `--dry-run`；用户要求先审核时先取得本次发送确认。脚本仅渲染和发送，推进授权、Bug 确认和是否已发由中心查原记录判断。正文及真实结果回写阶段过程记录，不新增队列或外层重试。
## 检查与结果 ## 检查与结果
排障可用 `python scripts/dingtalk_notify.py check --at "完整姓名"`，省略 `--at` 只查登录；它联网但不发送，不是每轮必做。两个发送入口加 `--dry-run` 可完全离线预览，条目中的标记显示为“@姓名”；不查人、不验证目标或 @ 效果。 排障可用 `python scripts/dingtalk_notify.py check --at "完整姓名"`，省略 `--at` 只查登录；它联网但不发送，不是每轮必做。两个发送入口加 `--dry-run` 可完全离线预览，条目中的标记显示为“@姓名”；不查人、不验证目标或 @ 效果。
plugins/codex/plugins/etunel-role-collaboration/skills/ep-hub/references/document-templates.md
+2
View File
@@ -2,6 +2,8 @@
仅在选择已有专业模板或历史样例时读取。中心维护的项目、阶段和任务模板见 [记录与留档](project-records.md)。 仅在选择已有专业模板或历史样例时读取。中心维护的项目、阶段和任务模板见 [记录与留档](project-records.md)。
项目计划的默认 Excel 模板及维护规则见 [项目计划](project-planning.md)。已有主表沿用已确认格式。结项报告和汇总按项目已确认格式制作，单工作表 Excel 仅作参考；不因模板字段齐全就补造工时、轮次、评审、签名或确认。
- 从当前任务、有效流程基线、成果、平台／机型、SDK 和版本选择适用资料；不因目录有多份就全部要求提交。 - 从当前任务、有效流程基线、成果、平台／机型、SDK 和版本选择适用资料；不因目录有多份就全部要求提交。
- 区分空白模板、历史样例、平台规范、器件输入与当前项目成果。只复用适用栏目和组织方式，旧人员、日期、参数、执行结果及签名不作为当前事实。 - 区分空白模板、历史样例、平台规范、器件输入与当前项目成果。只复用适用栏目和组织方式，旧人员、日期、参数、执行结果及签名不作为当前事实。
- 角色真人决定专业内容及内部制作方法。中心不将模板每一栏变成额外任务，不要求新增内部评审步骤；结果要求按 [八阶段与结果要求](project-lifecycle.md)。 - 角色真人决定专业内容及内部制作方法。中心不将模板每一栏变成额外任务，不要求新增内部评审步骤；结果要求按 [八阶段与结果要求](project-lifecycle.md)。
plugins/codex/plugins/etunel-role-collaboration/skills/ep-hub/references/exceptions-and-decisions.md
+18
View File
@@ -25,3 +25,21 @@
- **测试不通过拟放行**：必须有项目、产品双方真人明确核实，记录版本、不通过项与实际影响、剩余问题及责任、依据、放行范围与条件、双方确认人和时间；原测试结果保留不通过。实质变化重新核实。 - **测试不通过拟放行**：必须有项目、产品双方真人明确核实，记录版本、不通过项与实际影响、剩余问题及责任、依据、放行范围与条件、双方确认人和时间；原测试结果保留不通过。实质变化重新核实。
未知影响不写“无影响”，未知责任或日期不编造；汇总为需要真人决定的具体问题。已有明确停止事项、暂不修复或无需新增清单等条件必须沿用，不借汇报重新分配。 未知影响不写“无影响”，未知责任或日期不编造；汇总为需要真人决定的具体问题。已有明确停止事项、暂不修复或无需新增清单等条件必须沿用，不借汇报重新分配。
## Bug 处理与双方最终确认
结项前对全部 Bug 的处理或承接核对双方确认，包含此前已处理及后续发现的问题。沿用原测试报告、Bug 系统或阶段七共用遗留记录，不要求测试再交独立清单。日常进展据实更新；以下是处理或承接结论的确认顺序，不把每次状态更新变成重复审批。
1. 中心真人先确认问题事实、对象及版本、实际处理结果或承接安排。事实未确认前，不要求产品代为调查中心尚未核实的事实。
2. 产品真人在上述事实基础上再次确认，并在自身权限内决定处理方式。产品调整处理方案时，中心协调受影响的安排，再补受影响部分的确认。
3. 双方无异议后，在原记录登记最终结论、范围、条件与后续安排。已有适用于当前对象、版本和范围的有效确认直接引用，仅补缺失或变化部分。
每项保留：
- **问题**：已有 Bug 编号或名称、原记录入口、对象及版本。
- **实际状态**：已修复、延期、暂不修复或其他真实状态；处理方式已确认不等于问题已修复。
- **中心确认**：实际确认人、时间、事实与结论、范围、条件和来源。
- **产品确认**：实际确认人、时间、再次确认及处理决定、权限范围、条件和来源。
- **承接与分歧历史**：主责、下一步、原计划与当前计划、影响、必须完成阶段；保留每次调整、分歧及最终决定。
双方无异议可以对应修复、延期或暂不修复，不代表全部已修复或测试通过；不因此重测已有有效验收结果。后续发现的问题依同一确认顺序处理，按原责任或新的明确授权跟进，不自动撤销既有关闭决定。
plugins/codex/plugins/etunel-role-collaboration/skills/ep-hub/references/hub-workflow.md
+14 -7
View File
@@ -6,7 +6,7 @@
读取当前项目概览、进度和正在处理的任务，确认有效流程基线、当前阶段、中心真人负责人、相关角色真人及已有决定。沿用已有项目记录，不因安装新 Skill 自动迁移项目或重开中心会话。实际人员与接收对象取自已确认记录及当前运行时信息，不从示例推断。 读取当前项目概览、进度和正在处理的任务，确认有效流程基线、当前阶段、中心真人负责人、相关角色真人及已有决定。沿用已有项目记录，不因安装新 Skill 自动迁移项目或重开中心会话。实际人员与接收对象取自已确认记录及当前运行时信息，不从示例推断。
开始阶段时向负责人说明三类内容：本阶段必须完成、后续阶段处理、当前不需要。以后阶段的资料不提前成为当前完成条件。阶段 4、8 由中心真人组织，Agent 可协助整理；其他阶段按主责真人组织工作。 开始阶段时向负责人说明三类内容：本阶段必须完成、后续阶段处理、当前不需要；先汇报安排，再按真人决定执行。以后阶段的资料不提前成为当前完成条件。阶段 4、8 由中心真人组织，Agent 可协助整理；其他阶段按主责真人组织工作。排期和资源协调按 [项目计划](project-planning.md) 办理。
## 交付任务 ## 交付任务
@@ -34,14 +34,21 @@
1. 登记实际提交时间、成果版本和位置、提交人的完成说明以及已有真人确认。 1. 登记实际提交时间、成果版本和位置、提交人的完成说明以及已有真人确认。
2. 核对结果是否对应任务要求、必需项是否齐备、版本及确认范围是否一致、依赖和授权是否满足。链接内容由真人核实，中心不代作专业审查。 2. 核对结果是否对应任务要求、必需项是否齐备、版本及确认范围是否一致、依赖和授权是否满足。链接内容由真人核实，中心不代作专业审查。
3. 缺口只退回受影响部分，保留有效成果。已提交但未确认完成时保持“待确认”，不登记实际完成时间。 3. 缺口只退回受影响部分，保留有效成果。已提交但未确认完成时保持“已提交，待确认”，不登记实际完成时间。本人说明已通过其他渠道提交时据实登记，入口缺失、接收可用待确认、验收未确认分别记录，不因聊天无附件或队列待投递改成未提交。
4. 取得任务所需的真人完成确认后，按真实确认时间记录实际完成时间；正式成果与对应确认按 [成果与确认](artifacts-and-confirmation.md) 留存。 4. 取得任务所需的真人完成确认后，按真实确认时间记录实际完成时间；正式成果与对应确认按 [成果与确认](artifacts-and-confirmation.md) 留存。
5. 更新阶段逐任务汇总、项目进度和当前成果索引，再交接下游所需材料。 5. 更新阶段逐任务汇总、项目进度和当前成果索引；有计划主表时据真实回报同步实际执行情况，再交接下游所需材料。需要阶段决定或出现实质变化时主动在中心会话汇报。
## 阶段交接与关闭 ## 阶段交接与关闭
- 向中心真人逐条展示本阶段每项任务的成果、完成与确认情况，以及未完成项、影响、责任、原计划和当前计划时间、必须完成的阶段。 - 按 [阶段汇报与推进决定](stage-reporting.md) 主动向中心真人逐条汇报本阶段每项任务的成果、完成与确认情况，以及未完成项、影响、责任、原计划和当前计划时间、必须完成的阶段。请求查看确认前提供全部有效文件的完整入口；本地更新不替代聊天汇报。
- 中心真人决定推进、补充、退回或暂缓，Agent 记录决定及范围；缺项未解决时如实说明例外和承接，不写成正常通过。 - 中心真人决定推进、补充、退回或暂缓，Agent 记录决定及范围；已有条件授权实际满足后依授权执行并留依据，不重复申请。缺项未解决时如实说明例外和承接，不写成正常通过。
- 阶段结束逐条提醒仍待交的延期成果，持续至交付或有明确处置；只影响部分任务时不停止无关工作。 - 阶段结束逐条提醒仍待交的延期成果，持续至交付或有明确处置；只影响部分任务时不停止无关工作。
- 下一阶段引用已有成果和确认，不重复转存大文件、不因换阶段重派同一未完成任务。 - 下一阶段引用已有成果和确认，不因换阶段强制重复转存大文件或重派同一未完成任务。已批准的交接，在通知授权范围内合并发送上一阶段总结与下一阶段安排，正文和发送结果进入阶段过程记录。
- 进入复盘结项只表示开始结项整理。业务确认结项、中心真人决定关闭后才记录关闭；未交付的承接项仍保持待交和后续跟进状态。 - 进入复盘结项只表示开始结项整理。满足阶段八的必要条件，包括全部 Bug 处理或承接取得双方确认、业务确认结项后，由中心真人决定关闭；未交付的承接项仍保持待交和后续跟进状态。
## 关闭后的同步
- 记录关闭决定人、真实日期、原话、范围与条件；同步项目概览、进度、阶段、原任务、成果索引、结项报告和流程闭环总结，引用同一决定依据。
- 锁定当前有效成果，保留旧版和历史；停止已结束阶段、已确认成果的重复催办。仍需跟进的承接项按原责任和计划记录。
- 队列未送达、工具未结算单独记录，不能推翻真人关闭决定或重派同一业务任务。关闭不证明测试通过、Bug 已修复、已量产或已出货。
- 在已授权范围内发送一次结项总结，后续补地址或整理文件不重复发送。项目反馈留在实际项目，拟整合到共享 Skill 的内容和入口须经有权真人统一确认范围后再修改；关闭本身不代表共享规则变更授权。
plugins/codex/plugins/etunel-role-collaboration/skills/ep-hub/references/project-lifecycle.md
+15 -8
View File
@@ -4,7 +4,7 @@
## 通用推进规则 ## 通用推进规则
- 正常顺序按以下八阶段；每次跨阶段推进由中心真人决定，不因 Agent 判断满足条件自动进入下一阶段。 - 正常顺序按以下八阶段；每次跨阶段须有中心真人决定。已有条件授权实际满足时，按原范围执行并记录授权、条件依据和实际切换日期，不重复申请；无授权时不因 Agent 判断满足条件自动推进。详见 [阶段汇报与推进决定](stage-reporting.md)。
- 必需成果不能如期交付时，按 [异常与决定](exceptions-and-decisions.md) 记录真人确认、影响和补齐／承接安排。延期不等于交付，跳转不等于通过。 - 必需成果不能如期交付时，按 [异常与决定](exceptions-and-decisions.md) 记录真人确认、影响和补齐／承接安排。延期不等于交付，跳转不等于通过。
- 选填成果未提交不阻塞、无需豁免；已提供时登记有效版本及专业结论。可靠性、专项、提测佐证是否提交由中心真人决定，沿用已有有效决定。 - 选填成果未提交不阻塞、无需豁免；已提供时登记有效版本及专业结论。可靠性、专项、提测佐证是否提交由中心真人决定，沿用已有有效决定。
- 下面的成果名称可由连贯成果包承载，已经有效的同内容成果无需重做。既有记录能够承载专业结论时，不为配齐文件名新增文档。 - 下面的成果名称可由连贯成果包承载，已经有效的同内容成果无需重做。既有记录能够承载专业结论时，不为配齐文件名新增文档。
@@ -32,10 +32,10 @@
## 阶段四：项目规划 ## 阶段四：项目规划
- **组织者**：中心真人；技术负责人、产品及执行真人提供评估，Agent 协助汇总。 - **组织者**：中心真人负责总排期与跨角色资源协调；技术负责人、产品及执行真人按职责提供评估，Agent 协助汇总。
- **成果**：《项目计划》、《角色分工》、《项目状态内部记录》。 - **成果**：《项目计划》、《角色分工》、《项目状态内部记录》。
- **结果内容**：计划含任务拆分、工时评估、实际排期；技术负责人给出技术结构、顺序与依赖结论。分工明确每项任务主责、协作、人员变化与交接，引用立项资料中的风险，不另建风险成果或《产品资料整合》。 - **结果内容**：先交接全部有效产品需求，再由应用层、底层和硬件分别评估范围、已有成果、剩余工作、工时、周期、投入及等待。初版与后续迭代分开，技术负责人核实范围、先后、并行、合版和依赖后交测试衔接周期；测试可先估自身工作量。评估沿原任务留表，具体字段、八列唯一计划主表和执行更新见 [工时、周期与项目计划](project-planning.md)。分工明确每项任务主责、协作、人员变化与交接，引用立项资料中的风险，不另建风险成果或《产品资料整合》。
- **推进依据**：技术结构及问题任务已有结论，产品确认授权范围内资源和排期，预算、采购、对外承诺等必要业务授权完成，首批任务输入与依赖就绪；中心真人决定推进。不要求全员重签整份计划，同步业务的回执不增加批准条件。 - **推进依据**：技术结构及问题任务已有结论，中心真人统筹的整体排期和跨角色资源安排已明确，产品确认具体授权范围内的资源和排期，预算、采购、对外承诺等必要业务授权完成，首批任务输入与依赖就绪；中心真人决定推进。产品不默认承担全部专业和工厂周期，不要求全员重签整份计划，同步业务的回执不增加批准条件。
## 阶段五：嵌入式软硬件实现 ## 阶段五：嵌入式软硬件实现
@@ -48,7 +48,9 @@
| 嵌入式应用层 | 嵌入式应用层固件包 | 正式／升级固件、自测用例、分区表、MD5 值文件、Flash 烧写固件、zn_debug 文件、Changelog、串口使能证书 | | 嵌入式应用层 | 嵌入式应用层固件包 | 正式／升级固件、自测用例、分区表、MD5 值文件、Flash 烧写固件、zn_debug 文件、Changelog、串口使能证书 |
- 硬件设计需要实际外设、关键器件规格书和结构板框图；缺失只影响对应任务，不将前置输入重新列为产出，不另设《硬件实现资料》。 - 硬件设计需要实际外设、关键器件规格书和结构板框图；缺失只影响对应任务，不将前置输入重新列为产出，不另设《硬件实现资料》。
- 软硬件、环境或样机缺失只阻塞依赖它的工作，其他输入就绪的任务继续。到样、系统、PQ、AI 和环境状态取自真人实际回报，不按计划日期推定，也不把收到输入写成后续工作已完成。
- 底层提供可消费 BSP／PSP，应用层负责合版并交唯一最终提测固件；底层不直接交最终固件给测试，定频固件仅供专项测试。 - 底层提供可消费 BSP／PSP，应用层负责合版并交唯一最终提测固件；底层不直接交最终固件给测试，定频固件仅供专项测试。
- PSP 仓库／commit、BSP 构建及输入入口不等于最终固件身份，不将其他构建结果移用于最终包。现有配置中已有有效 BSP 消费入口，且真人确认无需另行获取时，直接沿用。已知包身份和入口交相关真人确认可用，Agent 无法访问不构成重做或反复上传的理由。
- 设计、自测、联调由真人自行组织，中心核对提交结果。**推进依据**：适用成果齐备，最终统一固件和硬件版本匹配，技术负责人明确可提测，中心真人决定推进。 - 设计、自测、联调由真人自行组织，中心核对提交结果。**推进依据**：适用成果齐备，最终统一固件和硬件版本匹配，技术负责人明确可提测，中心真人决定推进。
## 阶段六：测试验证 ## 阶段六：测试验证
@@ -56,8 +58,8 @@
- **主责**：测试，实际需要修复时由对应实现角色主责修复任务。 - **主责**：测试，实际需要修复时由对应实现角色主责修复任务。
- **成果**：《功能测试报告》必需，含通过／不通过结论、覆盖范围、用例执行结果及 bug log。缺陷信息可提供链接，**不要求缺陷清单文件，零缺陷也不另交零缺陷清单**。 - **成果**：《功能测试报告》必需，含通过／不通过结论、覆盖范围、用例执行结果及 bug log。缺陷信息可提供链接，**不要求缺陷清单文件，零缺陷也不另交零缺陷清单**。
- **选填**：《可靠性测试报告》（高低温，跌落／防水选填）、《专项测试报告》、《提测佐证》（视频、截图、log）。中心真人决定是否提交，未提供不阻塞，仍须执行已约定必测范围；外部平台要求与内部提交决定分开记录。 - **选填**：《可靠性测试报告》（高低温，跌落／防水选填）、《专项测试报告》、《提测佐证》（视频、截图、log）。中心真人决定是否提交，未提供不阻塞，仍须执行已约定必测范围；外部平台要求与内部提交决定分开记录。
- **输入与修复**：使用统一固件、版本矩阵、测试计划及必要变更说明。底层实现资料、硬件设计包不作为常规必交输入。测试自行制定每次执行、复测和回归策略，不增加独立策略文件或审批。真人商议缺陷责任，每项缺陷一个主责角色和责任人；需修复时中心安排交付任务。底层修复由应用层重新合版，硬件 ECO 随结果交兼容、应用有效性及版本矩阵更新结论，测试独立复验。 - **输入与修复**：每轮明确统一固件和硬件版本、版本矩阵、测试计划、变更、必测范围、期限及提交要求。底层实现资料、硬件设计包不作为常规必交输入。测试自行制定每次执行、复测和回归策略，不增加独立策略文件或审批。真人商议缺陷责任，每项缺陷一个主责角色和责任人；需修复时中心安排交付任务。底层修复由应用层重新合版，硬件 ECO 随结果交兼容、应用有效性及版本矩阵更新结论，测试独立复验。
- **提交确认**：测试真人提交后，中心真人须实际查看并明确确认或退回测试结果；确认前不宣布正式测试提交完成或进入正式验收。实质变化后的结果／被测版本重新确认。 - **提交确认**：测试真人提交后，中心真人须实际查看并明确确认或退回测试结果；确认前记录“已提交，待确认”，不写未提交，也不宣称已确认完成或进入正式验收。实质变化后的结果／被测版本重新确认。
- **推进依据**：测试通过并获中心真人确认推进；或测试不通过，但项目与产品双方真人核实后明确同意该版本放行，再由中心记录放行及推进决定。保留原“不通过”，分别记录放行版本、范围、条件、未通过项、责任安排及双方确认。放行不代表外部验收通过。 - **推进依据**：测试通过并获中心真人确认推进；或测试不通过，但项目与产品双方真人核实后明确同意该版本放行，再由中心记录放行及推进决定。保留原“不通过”，分别记录放行版本、范围、条件、未通过项、责任安排及双方确认。放行不代表外部验收通过。
## 阶段七：内部／外部验收 ## 阶段七：内部／外部验收
@@ -65,14 +67,19 @@
- **组织者**：项目；内部任务交相应真人，外部平台由产品确认、客户由业务确认。 - **组织者**：项目；内部任务交相应真人，外部平台由产品确认、客户由业务确认。
- **成果**：内部验收结果记入已有验收记录；产品汇总《平台验收报告或结论》《客户验收通过报告》及共用《遗留问题清单》，按项目已约定的适用验收范围办理。 - **成果**：内部验收结果记入已有验收记录；产品汇总《平台验收报告或结论》《客户验收通过报告》及共用《遗留问题清单》，按项目已约定的适用验收范围办理。
- **交接**：测试真人直接向产品真人交付已确认最终测试报告及已提供的提测佐证；中心沿用正式成果与确认，产品接收情况放过程记录。链接交付只记地址，不要求中心收转大文件。 - **交接**：测试真人直接向产品真人交付已确认最终测试报告及已提供的提测佐证；中心沿用正式成果与确认，产品接收情况放过程记录。链接交付只记地址，不要求中心收转大文件。
- **执行分工**：联系平台、发包寄样、收件和跟进按具体项目明确唯一主责，不默认全部由产品或中心本人执行。实际协调、接收可用、平台结果和业务客户确认分别记录。
- **结果内容**：遗留清单标明内部／外部来源、实际验收方、版本、责任人、处置和状态。平台无需业务再次批准；客户报告由产品出具或更新，客户结果由业务确认。各项输入就绪可并行，客户反馈由有联络权限的真人取得。 - **结果内容**：遗留清单标明内部／外部来源、实际验收方、版本、责任人、处置和状态。平台无需业务再次批准；客户报告由产品出具或更新，客户结果由业务确认。各项输入就绪可并行，客户反馈由有联络权限的真人取得。
- **推进依据**：约定的内部验收完成，适用外部验收取得对应真人确认；同时要求平台和客户验收时两项均须通过。版本一致、风险有承接，中心真人同意进入结项。内部验收或版本放行不能代替外部结果。 - **推进依据**：约定的内部验收完成，适用外部验收取得对应真人确认；同时要求平台和客户验收时两项均须通过。版本一致、风险有承接，中心真人同意进入结项。内部验收或版本放行不能代替外部结果。
- **返工**：回到受影响环节。新测试结果重新执行阶段六的真人确认；仍不通过拟放行时重新取得项目、产品双方结论。版本变化影响其他验收项时更新对应结果。 - **返工**：回到受影响环节。新测试结果重新执行阶段六的真人确认；仍不通过拟放行时重新取得项目、产品双方结论。版本变化影响其他验收项时更新对应结果。
- 共用遗留记录延续到阶段八的 Bug 双方确认，不给测试追加重复缺陷清单。
## 阶段八：复盘结项 ## 阶段八：复盘结项
- **组织者**：中心真人，各角色提供已有成果及复盘输入，Agent 协助整理，业务保留结项确认职责。 - **组织者**：中心真人，各角色提供已有成果及复盘输入，Agent 协助整理，业务保留结项确认职责。
- **成果**：《结项资料归档》、《变更记录》、《结项报告》、《流程闭环总结》。 - **成果**：《结项资料归档》、《变更记录》、《结项报告》、《流程闭环总结》。
- **结果内容**：归档沿用已验收最终版及确认；过程资料包括草稿、旧版、历史确认、变更过程、进度和接收记录，单独保留。复盘说明目标完成、计划偏差、协作与质量问题、经验和改进；改进项写入流程闭环总结，明确责任与跟进，不另设正式成果。 - **结果内容**：归档沿用已验收最终版及确认，逐项包含全部有效资料、配套资料或完整外部入口，不能只给目录或确认记录。阶段管理起止及依据写入既有《结项资料归档》，提交、采用、确认和工程实际日期分别记录，参见 [归档栏目](../assets/templates/结项资料归档.md)。过程资料包括草稿、旧版、历史确认、变更过程、进度和接收记录，单独保留。复盘说明目标完成、计划偏差、协作与质量问题、经验和改进；改进项写入流程闭环总结，明确责任与跟进，不另设正式成果。
- **关闭依据**：约定内部与外部验收已确认，归档可追踪、复盘完成、遗留已处理或落实承接，业务确认结项，中心真人决定关闭。结项必需项完成后锁定四类成果。仍有延期成果时，由中心真人明确补齐或承接安排后决定是否关闭，待交仍写待交，不伪报已归档。 - **成果格式**：结项报告及汇总沿用项目已确认格式；单工作表 Excel 只是可参考形式，不强制各项目采用同一表或字段。缺少工时、迭代、评审或签名时保留未知，不从文件数量推算或补造。
- **Bug 处理**：覆盖全部 Bug，包括已处理及后续发现项。中心真人先确认事实和实际处理／承接，产品真人再次确认并在职责内决定处理，双方无异议后登记最终确认；复用有效确认。具体顺序和字段见 [Bug 双方确认](exceptions-and-decisions.md#bug-处理与双方最终确认)。
- **关闭依据**：约定内部与外部验收已确认，归档可追踪、复盘完成、遗留已处理或落实承接，Bug 处理或承接已取得中心及产品双方确认，业务确认结项，中心真人决定关闭。结项必需项完成后锁定四类成果。仍有延期成果时，由中心真人明确补齐或承接安排后决定是否关闭，待交仍写待交，不伪报已归档。
- 本阶段不安排冒烟、发布验证或重做固件；新实现／质量问题回相应环节。开始整理不等于关闭，结项不等于后续改进全部完成；模拟只能记录模拟完成。 - 本阶段不安排冒烟、发布验证或重做固件；新实现／质量问题回相应环节。开始整理不等于关闭，结项不等于后续改进全部完成；模拟只能记录模拟完成。
- **关闭后**：按 [中心工作流](hub-workflow.md#关闭后的同步) 同步全部相关记录、锁定有效成果、停止重复催办并按授权发送一次结项总结。队列待送和工具未结算另记，不撤销真人关闭或重派业务任务；失败测试、未修复 Bug 和后续责任如实保留，不据此声称量产出货。
plugins/codex/plugins/etunel-role-collaboration/skills/ep-hub/references/project-planning.md
+36
View File
@@ -0,0 +1,36 @@
# 工时、周期与项目计划
阶段四组织评估、编排计划或后续更新执行情况时读取。中心真人统筹总排期和跨角色资源；角色真人决定本领域的执行方法。已有项目沿用已确认的唯一计划主表，新项目默认使用 [Excel 八列计划模板](../assets/templates/项目计划.xlsx)。Markdown 项目进度只维护摘要和主表入口。
## 收集评估与衔接周期
1. 评估前，向嵌入式应用层、嵌入式底层、硬件三方交接全部有效产品需求文件，列明版本和完整入口。各方分别说明本人范围、已有成果、剩余工作、尚不能估算的部分、可投入人员及外部等待。
2. 初版单列，后续迭代轮数不包含初版；每轮内容和周期可以不同。研发开发、自测、修复与独立测试、回归分别记录，外部等待另列。
3. 三方提交周期后，由技术负责人核实范围、遗漏与重复、先后和并行、合版以及软硬件依赖，再交测试衔接初版、各轮和回归周期及资源。测试可以先估自身工作量，不必等其他领域全部完成才开始评估。
4. 产品只确认明确授权范围内的具体资源和排期对象，记录权限及范围；不默认产品对全部专业工作或工厂周期负责。预算、采购、对外承诺等仍按业务权限办理，不要求全员重批整份计划。
评估沿原任务按工作项用表格记录，可嵌入 [工时与周期评估栏目](../assets/templates/工时与周期评估.md)。保留主责真人、原估／当前估及单位、周期及起算条件、投入和等待、提交与确认日期、来源和状态。变更保留前后值、原因及真人确认；未知写待确认，不能把工作日直接换成人日或小时。
## 唯一计划主表
固定八列：**里程碑、工作项、预排开始日期、预排结束日期、预排工时/人时、负责角色、参与人数、实际执行情况**。
- 空白模板不预填日期、工时、人数、任务或迭代轮数。根据项目真实评估展开工作项；不同项目不套用同一套参考任务或周期。
- 工时是任务合计人时，不再乘参与人数。人数不表示资源已落实；空白和 NA 不改成零。工作周期、工时、投入和外部等待分别记录。
- 客户目标、内部预计、当前有效计划和实际执行分开；客户验收目标与量产目标分别保留。计划主表显示当前已确认计划，原计划及历次改期保留在原任务记录中并可追溯。
- 预排日期不证明实际开始或完成；表格日期重叠不证明可并行、依赖已满足或已获跨阶段授权。
- 主表按项目已有位置维护；新项目在阶段四任务过程中编制，确认有效后按正式成果规则登记。后续持续使用同一主表，不另建 Markdown 全量副本。
## 更新实际执行情况
中心根据真实回报更新同一工作项的“实际执行情况”，按需要分行记录：
- 更新时间及事实来源。
- 已完成部分、未完成部分与当前进展。
- 真实开始和完成时间；任务实际完成仍取提交后真人明确确认完成的时间，工程实际发生时间另记。
- 成果名称、版本和实际入口，已有确认人、时间及范围。
- 偏差、影响、下一步，以及原任务记录入口。
没有回报时写“待补充执行情况”，不能推定未开始或未完成。日常事实更新直接据实登记并保留来源、历史，不重批整表。修改已确认日期、工作范围或资源安排时，由对应有权真人确认后更新当前计划，原值和决定保留在原任务／变更记录中。
已确认计划基线及历史版本仍按 [成果与确认](artifacts-and-confirmation.md) 保留。“实际执行情况”的后续更新应标明日期与来源，不把旧批准解释成对新发生事实的预先确认。
plugins/codex/plugins/etunel-role-collaboration/skills/ep-hub/references/project-records.md
+12 -6
View File
@@ -39,9 +39,11 @@
使用 [项目概览模板](../assets/templates/项目概览.md)。 使用 [项目概览模板](../assets/templates/项目概览.md)。
项目只有一份持续维护的计划主表。已有项目沿用已确认载体，新项目默认采用 [Excel 八列计划模板](../assets/templates/项目计划.xlsx)，实际主表在概览和进度中登记入口；评估、改期和实际执行的维护按 [项目计划规则](project-planning.md)。
### 项目进度 ### 项目进度
作为项目当前情况的统一入口，每次相关事实变化后同步维护： 作为项目当前情况的统一入口，每次相关事实变化后同步维护；计划主表保留完整工作项和实际执行，Markdown 只显示摘要和入口：
- **当前阶段与整体进度**：已完成、当前、后续阶段，关键成果与下一步。阶段完成依据真人决定；有跳转时如实标记，不将经过阶段等同于完成。 - **当前阶段与整体进度**：已完成、当前、后续阶段，关键成果与下一步。阶段完成依据真人决定；有跳转时如实标记，不将经过阶段等同于完成。
- **当前待处理事项**：逐项写事项、所属阶段、负责人、当前情况、下一步与需要谁决定。 - **当前待处理事项**：逐项写事项、所属阶段、负责人、当前情况、下一步与需要谁决定。
@@ -59,14 +61,14 @@
### 阶段记录 ### 阶段记录
顶部列阶段状态、时间和一句话进展。正文固定分为两类： 顶部列阶段状态、管理开始／完成日期、决定依据和一句话进展。开始取中心真人实际启用日期，完成取明确结束／进入下一阶段决定日期，第八阶段取关闭日期；进行中完成日期留空。已有条件授权时分别记录原授权、条件实际满足及实际切换日期，管理交接日期取实际切换日期。工程实际日期另记，不用管理日期计算工程延期或人时。正文固定分为两类：
1. **正式成果及确认记录**：每项最终成果单列名称、版本、位置或链接；对应真人确认逐项列确认人、时间、对象和版本、结论、范围与条件。历史确认留在过程区。 1. **正式成果及确认记录**：每项最终成果单列名称、版本、位置或链接；对应真人确认逐项列确认人、时间、对象和版本、结论、范围与条件。历史确认留在过程区。
2. **过程记录**：逐项汇总本阶段每个任务的负责人、应交／已交成果、完成情况、确认情况、原计划／当前计划／实际完成时间、缺口、影响、下一步及原任务入口。这里也列跨阶段引用、待确认成果、阶段决定、延期和历史资料入口。 2. **过程记录**：逐项汇总本阶段每个任务的负责人、应交／已交成果、完成情况、确认情况、原计划／当前计划／实际完成时间、缺口、影响、下一步及原任务入口。这里也列跨阶段引用、待确认成果、阶段决定、延期和历史资料入口。
每个任务都要覆盖成果、完成和确认三方面，不能只给过程文件链接。阶段已结束仍有未完成事项时，继续更新该阶段任务摘要并在项目层跟进；不因跨阶段复制任务。 每个任务都要覆盖成果、完成和确认三方面，不能只给过程文件链接。阶段已结束仍有未完成事项时，继续更新该阶段任务摘要并在项目层跟进；不因跨阶段复制任务。
阶段结束的正式小结只含最终成果与确认，未决项和后续安排放过程栏目。使用 [阶段记录模板](../assets/templates/阶段记录.md)。 阶段结束的正式小结只含最终成果与确认，未决项和后续安排放过程栏目。中心聊天汇报及群交接总结、发送实际结果也留在过程栏目，避免同一交接重复发送。使用 [阶段记录模板](../assets/templates/阶段记录.md)，主动汇报见 [阶段汇报](stage-reporting.md)。
### 任务记录 ### 任务记录
@@ -81,19 +83,23 @@
使用 [任务记录模板](../assets/templates/任务记录.md)。 使用 [任务记录模板](../assets/templates/任务记录.md)。
需要工时或周期评估时在原任务嵌入 [评估栏目](../assets/templates/工时与周期评估.md)。涉及 Bug 处理或承接时沿原问题／共用记录保存 [双方确认字段](exceptions-and-decisions.md#bug-处理与双方最终确认)，不复制成另一份缺陷台账。
### 成果索引 ### 成果索引
按阶段列当前有效的最终成果名称、版本、位置及确认入口。确认详情只在对应阶段正式栏目维护，索引链接过去。任务状态、延期、草稿和旧版不混入当前成果索引。 按阶段列当前有效的最终成果名称、版本、位置及确认入口。确认详情只在对应阶段正式栏目维护，索引链接过去。任务状态、延期、草稿和旧版不混入当前成果索引。
使用 [成果索引模板](../assets/templates/成果索引.md)。原本就在外部系统的成果只记真实链接，不复制内容；外部系统旧版地址与历史情况放过程记录。 使用 [成果索引模板](../assets/templates/成果索引.md)。逐项登记全部有效成果和配套资料，或可逐项定位内容的有效包索引。原本在外部系统的成果登记真实完整地址、用途和版本，不强制复制；明确授权本地复制时按 [成果与确认](artifacts-and-confirmation.md) 保留原交接和路径映射，索引改为正式位置。复制或补地址日期不改变原提交、采用、确认和完成时间。
结项使用 [结项资料归档栏目](../assets/templates/结项资料归档.md)，属于既有四类结项成果之一。沿用项目确认的格式；目录或确认记录不代表全部原件已归档。
## 更新顺序与避免重复 ## 更新顺序与避免重复
1. 在原任务中记录新事实与来源，更新现状，追加必要历史。 1. 在原任务中记录新事实与来源，更新现状，追加必要历史。
2. 若涉及正式版本变化，按 [成果与确认](artifacts-and-confirmation.md) 保留旧版及旧确认，再登记新最终版。 2. 若涉及正式版本变化，按 [成果与确认](artifacts-and-confirmation.md) 保留旧版及旧确认，再登记新最终版。
3. 更新所属阶段的逐任务摘要；涉及后续阶段时只添加原任务引用。 3. 更新所属阶段的逐任务摘要；涉及后续阶段时只添加原任务引用。
4. 同步项目进度的当前事项、影响与时间；正式成果变化时更新成果索引。 4. 同步项目进度的当前事项、影响与时间；有计划主表时据实更新执行情况并保留来源和历史；正式成果变化时更新成果索引。
5. 取得必要真人推进决定并留档后再推进；需要通知时从这些记录生成摘要。 5. 主动向中心真人汇报需要确认或决定的阶段结果；取得必要推进决定或既有条件授权实际满足并留档后再推进。需要通知时从这些记录生成摘要，正文及真实发送结果记入过程记录。
若更新中断，继续前核对原记录、阶段和项目摘要是否一致，以真实事实和确认依据为准补齐，不凭较新的文件时间覆盖业务结论。中心不新增一套任务数据库、通知队列或同步服务。 若更新中断，继续前核对原记录、阶段和项目摘要是否一致，以真实事实和确认依据为准补齐，不凭较新的文件时间覆盖业务结论。中心不新增一套任务数据库、通知队列或同步服务。
plugins/codex/plugins/etunel-role-collaboration/skills/ep-hub/references/stage-reporting.md
+35
View File
@@ -0,0 +1,35 @@
# 阶段汇报与推进决定
阶段结果需要确认、未完成事项需要决定或准备交接阶段时读取。汇报发在项目持续使用的中心会话中；更新本地记录不能替代向中心真人汇报。群通知另按 [通知规则](dingtalk-progress-reporting.md) 执行。
## 何时主动汇报
- 本阶段任务已全部确认完成，需要决定是否推进。
- 成果已提交但还有必要确认，或存在未完成、延期和跨阶段承接事项，需要中心真人决定。
- 已汇报的成果、版本、确认或遗留发生实质变化，补充受影响部分。
先更新原任务、阶段、项目进度及适用成果索引，再用 [阶段成果汇报栏目](../assets/templates/阶段成果汇报.md) 逐条汇报。可直接用于聊天，不为每次汇报另建独立成果文件；在阶段过程记录保留本次汇报与决定的依据。
## 汇报什么
1. 项目名称、本次汇报日期、当前阶段、阶段状态及概况。
2. 本阶段每项任务的主责真人、完成情况、应交成果、必需／选填与适用条件、已交成果及版本、完整入口。对应真人确认逐项写确认人、真实时间、结论、对象、范围与条件。
3. 原计划、当前有效计划、实际提交和实际完成时间；阶段管理日期与工程实际时间分开。
4. 未完成项和待确认项逐条说明原因、依赖、责任、原计划与当前计划、影响及必须完成的阶段。确实没有时明确写“未完成项：无；待确认项：无”；未知不填无。
5. 建议下一步及需要中心真人决定的具体事项。建议和已作出的决定分开，未决定保持待决定。
请求成果确认前，按 [成果与确认](artifacts-and-confirmation.md#供真人查看的成果) 展示本次全部有效成果的名称、版本、用途及完整可点击地址，或直接展示文件。目录或汇总描述不能代替实际查看入口。
## 推进和条件授权
跨阶段须有中心真人明确决定。已有条件授权时，逐项核实条件是否实际满足；满足后按原授权范围执行并记录依据，不重复申请同一批准。条件未满足、事实有变化或超出原范围时，说明缺口并取得相应决定。专业确认、业务授权及外部验收仍按各自权限办理。
在阶段过程记录分别保存：
- 原授权人、授权日期、原话、范围与条件。
- 条件实际满足的日期及各项证据。
- 实际切换日期和所执行的安排。
条件授权的阶段交接以实际切换日期登记阶段管理日期，不用早先授权日期倒填。正常阶段开始取中心真人实际启用日期，完成取明确结束或进入下一阶段的决定日期；第八阶段完成取明确关闭日期。进行中完成日期留空。工程开发、测试、验收的实际发生日期另行记录，不以阶段管理日期计算工程延期或人时。
取得推进决定或条件授权实际满足后，在已启用且获授权的范围内，将上一阶段总结与下一阶段已确认安排合为一条群通知。发送正文和实际结果记入阶段过程记录，核对既有记录避免同一次交接重复通知。
plugins/codex/plugins/find-skills/THIRD_PARTY_SOURCE.json
+2 -2
View File
@@ -2,8 +2,8 @@
"sourceId": "find-skills", "sourceId": "find-skills",
"repo": "https://github.com/vercel-labs/skills.git", "repo": "https://github.com/vercel-labs/skills.git",
"ref": "main", "ref": "main",
"commit": "13e4063a1cf913f5606d57d42ab83a86f5001e04", "commit": "a80e4c9d12d607631249d4d7d059f835d4b2f13a",
"adapter": "claude-skill", "adapter": "claude-skill",
"sourcePath": "skills/find-skills", "sourcePath": "skills/find-skills",
"syncedAt": "2026-10-10T16:00:00Z" "syncedAt": "2026-10-21T06:48:34Z"
} }
plugins/codex/plugins/grill-me/THIRD_PARTY_SOURCE.json
+2 -2
View File
@@ -2,8 +2,8 @@
"sourceId": "grill-me", "sourceId": "grill-me",
"repo": "https://github.com/mattpocock/skills.git", "repo": "https://github.com/mattpocock/skills.git",
"ref": "main", "ref": "main",
"commit": "49dd158d1076134a641b33efb035946536778336", "commit": "5beb35b040e3de97e54fa9e386d7e42d15c295c2",
"adapter": "skill-collection", "adapter": "skill-collection",
"sourcePath": "skills/productivity", "sourcePath": "skills/productivity",
"syncedAt": "2026-10-09T16:00:00Z" "syncedAt": "2026-10-21T06:48:34Z"
} }
plugins/codex/plugins/mcp-playwright/MCP_SOURCE.json
+1 -1
View File
@@ -3,5 +3,5 @@
"name": "playwright浏览器自动化操作", "name": "playwright浏览器自动化操作",
"version": "20260605", "version": "20260605",
"keySource": "none", "keySource": "none",
"syncedAt": "2026-10-17T16:02:40Z" "syncedAt": "2026-10-21T06:51:10Z"
} }
plugins/codex/plugins/next-skills/THIRD_PARTY_SOURCE.json
+2 -2
View File
@@ -2,8 +2,8 @@
"sourceId": "next-skills", "sourceId": "next-skills",
"repo": "https://github.com/vercel/next.js.git", "repo": "https://github.com/vercel/next.js.git",
"ref": "canary", "ref": "canary",
"commit": "e2e7393c1f8449759aa1ae502b64fd7e946fbf37", "commit": "72895219d44df111ee6ac81e4eac10d81a5e5cbf",
"adapter": "skill-collection", "adapter": "skill-collection",
"sourcePath": "skills", "sourcePath": "skills",
"syncedAt": "2026-10-17T16:00:00Z" "syncedAt": "2026-10-21T06:48:34Z"
} }
plugins/codex/plugins/ppt-master/README.md
+2 -8
View File
@@ -17,7 +17,7 @@ English | [中文](./README_CN.md)
## ❤️ Sponsors ## ❤️ Sponsors
This project is kept free and open source with the support of <a href="https://www.kimi.com/code/?aff=ppt-master">Kimi</a>, <a href="https://www.packyapi.ai/register?aff=ppt-master">PackyCode</a>, <a href="https://apikey.fan/register?aff=PPT-MASTER">APIKEY.FAN</a>, <a href="https://runapi.host/register?aff=WMLJ">RunAPI</a>, <a href="https://go.apimart.ai/gh-ppt-master1">APIMart</a> and other sponsors. This project is kept free and open source with the support of <a href="https://www.kimi.com/code/?aff=ppt-master">Kimi</a>, <a href="https://www.packyapi.ai/register?aff=ppt-master">PackyCode</a>, <a href="https://apikey.fan/register?aff=PPT-MASTER">APIKEY.FAN</a>, <a href="https://runapi.host/register?aff=WMLJ">RunAPI</a> and other sponsors.
> **[Want to appear here?](SPONSORING.md)** > **[Want to appear here?](SPONSORING.md)**
@@ -47,10 +47,6 @@ Thanks to [Kimi](https://www.kimi.com/code/?aff=ppt-master) for sponsoring this
<td width="180"><a href="https://runapi.host/register?aff=WMLJ"><img src="docs/assets/sponsors/runapi.png" alt="RunAPI" width="150"></a></td> <td width="180"><a href="https://runapi.host/register?aff=WMLJ"><img src="docs/assets/sponsors/runapi.png" alt="RunAPI" width="150"></a></td>
<td>Thanks to RunAPI for sponsoring this project! RunAPI is an efficient and stable API platform — a single API Key gives you access to 150+ leading models, including OpenAI, Claude, Gemini, DeepSeek, and Grok, at prices as low as <strong>10% of official rates</strong>, with exceptional stability and seamless compatibility with tools like Claude Code. RunAPI offers an exclusive perk for PPT Master users: register and contact an administrator via <a href="https://runapi.host/register?aff=WMLJ">our dedicated link</a> to claim <strong>¥7 in free credit</strong>.</td> <td>Thanks to RunAPI for sponsoring this project! RunAPI is an efficient and stable API platform — a single API Key gives you access to 150+ leading models, including OpenAI, Claude, Gemini, DeepSeek, and Grok, at prices as low as <strong>10% of official rates</strong>, with exceptional stability and seamless compatibility with tools like Claude Code. RunAPI offers an exclusive perk for PPT Master users: register and contact an administrator via <a href="https://runapi.host/register?aff=WMLJ">our dedicated link</a> to claim <strong>¥7 in free credit</strong>.</td>
</tr> </tr>
<tr>
<td width="180"><a href="https://go.apimart.ai/gh-ppt-master1"><img src="docs/assets/sponsors/apimart.png" alt="APIMart" width="150"></a></td>
<td>Thanks to APIMart for sponsoring this project! APIMart is a low-cost API platform for AI image & video generation — GPT-Image-2 from <strong>$0.006/image</strong>, 160+ images per dollar. One async API covers both image and video: submit a task, get an ID, fetch results via polling or callback. Batch tens of thousands of images without timeouts, switch models without changing code. Pay-as-you-go with no monthly fee — sign up <a href="https://go.apimart.ai/gh-ppt-master1">here</a> to get started.</td>
</tr>
</table> </table>
</details> </details>
@@ -101,7 +97,7 @@ Generating a new deck from source documents is the main pipeline, but not the on
On top of that native depth, this form comes with three promises: On top of that native depth, this form comes with three promises:
- **Transparent, predictable cost** — free and open source; the only cost is your AI model usage, with no PPT subscription on top - **Transparent, predictable cost** — free and open source; the only cost is your AI model usage, with no PPT subscription on top
- **Data stays local** — apart from AI model communication, the entire pipeline runs on your machine - **Data stays local** — apart from AI model calls and the search, image, and speech services you choose to enable, the entire pipeline runs on your machine
- **No platform lock-in** — any agent-capable AI IDE can drive it; Claude, GPT, Gemini, Kimi, and other models all work - **No platform lock-in** — any agent-capable AI IDE can drive it; Claude, GPT, Gemini, Kimi, and other models all work
Why you'd choose it, and where it isn't the right fit → [Why PPT Master](./docs/why-ppt-master.md); the long-term capability boundaries behind these promises → [Project Positioning](./docs/project-positioning.md). Why you'd choose it, and where it isn't the right fit → [Why PPT Master](./docs/why-ppt-master.md); the long-term capability boundaries behind these promises → [Project Positioning](./docs/project-positioning.md).
@@ -416,8 +412,6 @@ PPT Master is currently built and maintained primarily by me. Every new template
&nbsp; &nbsp;
<a href="https://runapi.host/register?aff=WMLJ"><img src="docs/assets/sponsors/runapi.png" alt="RunAPI" height="40" /></a> <a href="https://runapi.host/register?aff=WMLJ"><img src="docs/assets/sponsors/runapi.png" alt="RunAPI" height="40" /></a>
&nbsp; &nbsp;
<a href="https://go.apimart.ai/gh-ppt-master1"><img src="docs/assets/sponsors/apimart.png" alt="APIMart" height="40" /></a>
&nbsp;
<a href="https://m.do.co/c/547f129aabe1"><img src="https://opensource.nyc3.cdn.digitaloceanspaces.com/attribution/assets/PoweredByDO/DO_Powered_by_Badge_blue.svg" alt="Powered by DigitalOcean" height="40" /></a> <a href="https://m.do.co/c/547f129aabe1"><img src="https://opensource.nyc3.cdn.digitaloceanspaces.com/attribution/assets/PoweredByDO/DO_Powered_by_Badge_blue.svg" alt="Powered by DigitalOcean" height="40" /></a>
**[Want to appear here? →](SPONSORING.md)** — placements, audience and rates. **[Want to appear here? →](SPONSORING.md)** — placements, audience and rates.
plugins/codex/plugins/ppt-master/THIRD_PARTY_SOURCE.json
+2 -2
View File
@@ -2,8 +2,8 @@
"sourceId": "ppt-master", "sourceId": "ppt-master",
"repo": "https://github.com/hugohe3/ppt-master.git", "repo": "https://github.com/hugohe3/ppt-master.git",
"ref": "main", "ref": "main",
"commit": "b113d23720260c411ee47b2b05a73615f954deeb", "commit": "cc8b722a24e9fb540e67c2d58a9ea3da534cd682",
"adapter": "claude-skill", "adapter": "claude-skill",
"sourcePath": "skills/ppt-master", "sourcePath": "skills/ppt-master",
"syncedAt": "2026-10-17T16:00:00Z" "syncedAt": "2026-10-21T06:48:34Z"
} }
plugins/codex/plugins/ppt-master/skills/ppt-master/SPONSORS.md
-6
View File
@@ -40,12 +40,6 @@ Thanks to [Kimi](https://www.kimi.com/code/?aff=ppt-master) for sponsoring PPT M
[RunAPI](https://runapi.host/register?aff=WMLJ) provides access to 150+ models, including OpenAI, Claude, Gemini, DeepSeek, and Grok, through one API key. Register through the dedicated link and contact an administrator to claim **¥7 in free credit**. [RunAPI](https://runapi.host/register?aff=WMLJ) provides access to 150+ models, including OpenAI, Claude, Gemini, DeepSeek, and Grok, through one API key. Register through the dedicated link and contact an administrator to claim **¥7 in free credit**.
### APIMart
<a href="https://go.apimart.ai/gh-ppt-master1"><img src="https://raw.githubusercontent.com/hugohe3/ppt-master/main/docs/assets/sponsors/apimart.png" alt="APIMart" width="150"></a>
[APIMart](https://go.apimart.ai/gh-ppt-master1) is a low-cost API platform for AI image and video generation, with GPT-Image-2 from **$0.006 per image**. One async API covers both image and video: submit a task, get an ID, and fetch results by polling or callback. Pay-as-you-go with no monthly fee; register through the dedicated link to get started.
## Infrastructure Support ## Infrastructure Support
<a href="https://m.do.co/c/547f129aabe1"><img src="https://opensource.nyc3.cdn.digitaloceanspaces.com/attribution/assets/PoweredByDO/DO_Powered_by_Badge_blue.svg" alt="Powered by DigitalOcean" height="40"></a> <a href="https://m.do.co/c/547f129aabe1"><img src="https://opensource.nyc3.cdn.digitaloceanspaces.com/attribution/assets/PoweredByDO/DO_Powered_by_Badge_blue.svg" alt="Powered by DigitalOcean" height="40"></a>
plugins/codex/plugins/ppt-master/skills/ppt-master/SPONSORS_CN.md
-6
View File
@@ -40,12 +40,6 @@ PPT Master 始终免费开源。以下赞助方共同支持项目的持续维护
[RunAPI](https://runapi.host/register?aff=WMLJ) 通过一个 API Key 提供 OpenAI、Claude、Gemini、DeepSeek、Grok 等 150+ 主流模型。通过专属链接注册并联系管理员，即可领取 **¥7 免费额度**。 [RunAPI](https://runapi.host/register?aff=WMLJ) 通过一个 API Key 提供 OpenAI、Claude、Gemini、DeepSeek、Grok 等 150+ 主流模型。通过专属链接注册并联系管理员，即可领取 **¥7 免费额度**。
### APIMart
<a href="https://go.apimart.ai/gh-ppt-master1"><img src="https://raw.githubusercontent.com/hugohe3/ppt-master/main/docs/assets/sponsors/apimart.png" alt="APIMart" width="150"></a>
[APIMart](https://go.apimart.ai/gh-ppt-master1) 是专注 AI 图片/视频生成的低价 API 平台，GPT-Image-2 低至 **$0.006/张**。图片、视频共用一套异步 API：提交任务拿 ID，轮询或回调取结果。按量付费、无月费，通过专属链接注册即可开用。
## 基础设施支持 ## 基础设施支持
<a href="https://m.do.co/c/547f129aabe1"><img src="https://opensource.nyc3.cdn.digitaloceanspaces.com/attribution/assets/PoweredByDO/DO_Powered_by_Badge_blue.svg" alt="Powered by DigitalOcean" height="40"></a> <a href="https://m.do.co/c/547f129aabe1"><img src="https://opensource.nyc3.cdn.digitaloceanspaces.com/attribution/assets/PoweredByDO/DO_Powered_by_Badge_blue.svg" alt="Powered by DigitalOcean" height="40"></a>
plugins/codex/plugins/ppt-master/skills/ppt-master/requirements.txt
+1
View File
@@ -1,3 +1,4 @@
# -*- coding: utf-8 -*-
# PPT Master Dependencies / PPT Master 依赖 # PPT Master Dependencies / PPT Master 依赖
# ============================================= # =============================================
# #
plugins/codex/plugins/ppt-master/skills/ppt-master/workflows/profiles/image-to-pptx.md
+2
View File
@@ -87,6 +87,8 @@ The reference-image CLI does not inherit source dimensions: pass an explicit mat
Before deciding layers, write `<project_path>/analysis/reconstruction_inventory.json` recording only what is visibly present: original file and normalized page path; page order, source-frame bbox, SHA-256, pixel dimensions; visible regions with stable ids, bboxes, observed family (`text` / `graphic` / `image` / `unknown`), verbatim text where applicable, and confidence; observed sufficiency, boundary completeness, occlusion/contamination, and identity/data verifiability; overlap/z-order observations and unresolved evidence. No final layer choices, prompts, output filenames, or SVG bindings — those stay in active context plus required operational image evidence; context loss restarts the run. Low-confidence text, an uncertain boundary, or an unidentified branded/data graphic is unresolved evidence and blocks delivery. Before deciding layers, write `<project_path>/analysis/reconstruction_inventory.json` recording only what is visibly present: original file and normalized page path; page order, source-frame bbox, SHA-256, pixel dimensions; visible regions with stable ids, bboxes, observed family (`text` / `graphic` / `image` / `unknown`), verbatim text where applicable, and confidence; observed sufficiency, boundary completeness, occlusion/contamination, and identity/data verifiability; overlap/z-order observations and unresolved evidence. No final layer choices, prompts, output filenames, or SVG bindings — those stay in active context plus required operational image evidence; context loss restarts the run. Low-confidence text, an uncertain boundary, or an unidentified branded/data graphic is unresolved evidence and blocks delivery.
**Coordinate mapping**: source-frame bboxes use original-file pixels; region bboxes use normalized-page pixels. Map page-derived geometry and text metrics into canvas units with the same uniform scale and placement offset as the registered layers; for matching aspect ratios, `s = canvas width / page width` and the offset is zero. Apply the scale once to source-derived lengths, including font size, stroke width, and radii.
--- ---
## 6. Image Preparation ## 6. Image Preparation
plugins/codex/plugins/shadcn/THIRD_PARTY_SOURCE.json
+2 -2
View File
@@ -2,8 +2,8 @@
"sourceId": "shadcn", "sourceId": "shadcn",
"repo": "https://github.com/shadcn-ui/ui.git", "repo": "https://github.com/shadcn-ui/ui.git",
"ref": "main", "ref": "main",
"commit": "d2fba50ee5b9113008b5bb908563527b7efd2f27", "commit": "ba1503c64472b82256d9de95e2e62c5901a38e8b",
"adapter": "claude-skill", "adapter": "claude-skill",
"sourcePath": "skills/shadcn", "sourcePath": "skills/shadcn",
"syncedAt": "2026-10-17T16:00:00Z" "syncedAt": "2026-10-21T06:48:34Z"
} }
plugins/codex/plugins/taste-skill/.codex-plugin/plugin.json
+1 -1
View File
@@ -21,7 +21,7 @@
"interface": { "interface": {
"displayName": "Taste Skill", "displayName": "Taste Skill",
"shortDescription": "反模板化前端设计、重设计和图像参考生成 skill 集合。", "shortDescription": "反模板化前端设计、重设计和图像参考生成 skill 集合。",
"longDescription": "Taste Skill 提供 design-taste-frontend、gpt-taste、image-to-code、redesign、minimalist、brutalist、soft、stitch、output enforcement，以及 Web、移动端和 brandkit 图像生成等多个 skills，用于让 AI Agent 产出更有设计判断、更少模板感的前端界面和视觉参考。", "longDescription": "Taste Skill 提供反模板化前端设计、重设计、图像参考生成和高质量输出约束工作流，用于让 AI Agent 产出更有设计判断、更少模板感的前端界面。",
"developerName": "Leonxlnx", "developerName": "Leonxlnx",
"category": "Creativity", "category": "Creativity",
"capabilities": [ "capabilities": [
plugins/codex/plugins/taste-skill/THIRD_PARTY_SOURCE.json
+2 -2
View File
@@ -2,8 +2,8 @@
"sourceId": "taste-skill", "sourceId": "taste-skill",
"repo": "https://github.com/Leonxlnx/taste-skill.git", "repo": "https://github.com/Leonxlnx/taste-skill.git",
"ref": "main", "ref": "main",
"commit": "f624f37a8c650b9cc550253104925efe4c8de246", "commit": "6010f91a9935f1c167dfc500fb1a475681892e6b",
"adapter": "skill-collection", "adapter": "skill-collection",
"sourcePath": "skills", "sourcePath": "skills",
"syncedAt": "2026-10-14T16:00:00Z" "syncedAt": "2026-10-21T06:48:34Z"
} }
plugins/codex/plugins/taste-skill/skills/brandkit/SKILL.md
-843
View File
@@ -1,843 +0,0 @@
---
name: brandkit
description: "用于生成高端品牌指南、Logo 系统、视觉世界和品牌应用参考图的图像生成 skill。"
---
# BRANDKIT IMAGE GENERATION SKILL
You are an elite brand identity art director, logo designer, visual-system strategist, and presentation designer.
Your job is to generate premium brand-kit images that feel like they came from a serious identity studio.
The output must feel:
- intentional
- premium
- minimal
- coherent
- strategic
- visually expensive
- brand-system driven
- presentation-ready
Do not generate generic logos.
Do not generate random mockups.
Do not generate messy AI moodboards.
Create a complete brand world in one image.
---
# REFERENCE STYLE DNA
The desired visual quality is inspired by premium brand-guidelines decks with:
- dark charcoal outer canvas
- clean grid-based presentation boards
- strong gutters between panels
- restrained visual density
- very sparse typography
- large negative space
- cinematic brand atmosphere
- simple but memorable logo marks
- UI mockups used as brand applications
- browser chrome / app headers / terminal frames
- image-led panels with subtle overlays
- halftone, grain, scanline, or print texture
- geometric construction diagrams
- small labels and page-number details
- muted but powerful accent colors
- logo repeated across multiple touchpoints
- one strong brand idea per board
The references are not a fixed style.
They define the quality bar, restraint, and presentation logic.
---
# CORE PRINCIPLE
A premium brand kit is not decoration.
It is a visual argument for why the brand exists.
Every generated board must answer:
1. What does this brand represent?
2. What is the core metaphor?
3. How does the logo express that?
4. How does the system scale across UI, print, image, and detail?
5. Why does the whole thing feel ownable?
---
# DEFAULT OUTPUT
Unless the user specifies otherwise:
- Generate one brand-kit overview image
- Default layout: `3 × 3`
- Default aspect ratio: `4:3` or `16:10`
- Use a clean presentation grid
- Use consistent gutters
- Use minimal text
- Make every panel feel connected
Canvas size and aspect ratio describe the whole output image, not the panel grid.
Honor requested dimensions (width × height), aspect ratio, or orientation over the defaults. Include them in the internal prompt and use the generator's supported size or aspect-ratio controls accordingly.
If the generator cannot produce the exact requested dimensions or ratio, explain the limit and available alternatives. Use a supported size that preserves the requested ratio where possible. Ask the user to choose only when cropping, resizing, or changing the composition would materially affect the result. Report the actual output size; do not promise unsupported pixel dimensions.
Adapt the grid and spacing to square, portrait, or wide canvases without stretching panels. Keep the defaults when no custom size or layout is requested.
Allowed layouts:
- `3 × 3` full identity system
- `2 × 3` cinematic brand deck overview
- `2 × 2` compact concept board
- `1 × 3` horizontal brand strip
- `4 × 2` wide contact-sheet layout
- custom layout when requested
For inspiration references, match their quality and rhythm, not their exact content.
---
# BRAND INTAKE
Before image generation, determine whether this is a new identity or an extension of an existing brand. Choose based on the user's stated intent, not on whether assets are attached.
Use the request, earlier context, and supplied assets first. Do not ask again for information already provided.
If unclear, ask one short intake question covering only the missing details:
- create from scratch, extend, or refresh / rebrand
- existing logo / wordmark
- brand colors / palette
- typography / fonts
- visual direction / mood references
Inspiration or mood references alone do not establish an existing identity; treat them as brand constraints only when the user identifies them that way.
Choose the flow:
- **Create from scratch:** If the user requests a new identity or confirms that no existing brand identity applies, follow the full generation flow below.
- **Build on existing brand:** Reuse supplied logos, names, colors, typography, and direction consistently across the board and mockups. Do not invent replacements or reinterpret the logo.
For partial inputs, preserve supplied elements and develop only missing parts to fit them. If existing assets are needed but unavailable, request them and wait before generation.
An explicit refresh or rebrand request takes priority; change only the elements within the requested scope.
Existing identity constraints take priority over the style, palette, and new-logo defaults below.
---
# BRAND STRATEGY FIRST
Before generating, infer the brand strategy.
Think through:
- category
- audience
- product function
- emotional promise
- cultural position
- trust level
- visual world
- symbolic metaphor
- what the brand should avoid
The visual system must be based on meaning.
Examples:
| Category | Core Ideas | Possible Symbol Logic |
|---|---|---|
| Developer tool | building, speed, precision, control | cursor, frame, bolt, scaffold, grid |
| AI assistant | delegation, intelligence, clarity | spark, orbit, signal, path, node |
| Security | protection, vigilance, boundary | shield, eye, seal, protected core |
| Gaming / betting | chance, reward, tension, speed | dice, gem, card, signal, trophy |
| Voice AI | sound, rhythm, command, flow | waveform, mic, orb, speech path |
| Compliance | trust, order, rules, protection | seal, dog, badge, document, shield |
| Drone / robotics | flight, control, vision, mission | wing, owl, crosshair, path, zone |
| Luxury / editorial | taste, material, ritual, restraint | monogram, seal, paper, emboss, mark |
| Productivity | focus, momentum, clarity | path, check, block, calendar, light |
Do not pick symbols randomly.
---
# LOGO GENERATION STANDARD
Apply this section and the logo concept methods only when a new logo is needed or requested.
The logo must be professional.
It should be:
- simple
- memorable
- symbolic
- scalable
- ownable
- visually balanced
- connected to the brand idea
- usable as icon, wordmark, badge, UI mark, and pattern
Avoid:
- generic lightning bolts unless strongly justified
- random animals
- fake luxury crests
- copied famous marks
- overcomplicated symbols
- clipart-style icons
- meaningless sparkles
- inconsistent logo variants
The logo should feel like it came from research and reduction.
---
# LOGO CONCEPT METHODS
Use one or combine two maximum.
## 1. Monogram + Meaning
Combine the brand initial with a metaphor.
Examples:
- `K` + kite / frame / direction
- `N` + path / folded system
- `S` + sound wave / speech flow
- `A` + ascent / architecture / momentum
Do not make a boring letter icon.
Use negative space, cuts, folds, or geometry.
---
## 2. Product Action
Turn the product's main action into a symbol.
Examples:
- build → frame, scaffold, block, cursor
- protect → shield, boundary, watch mark
- convert → switch, arrow, transformation shape
- speak → waveform, mic, pulse
- hunt threats → eye, raptor, radar, trace
- automate → loop, handoff, path
Make it abstract and premium, not literal.
---
## 3. Metaphor Fusion
Combine two meaningful ideas into one reduced mark.
Examples:
- owl + drone vision
- shield + mountain
- moon + waveform
- dog + compliance seal
- dice + mobile game economy
- cursor + lightning speed
- kite + product frame
The fusion should be subtle and readable.
---
## 4. Negative Space
Use empty space to create intelligence.
Examples:
- hidden arrow
- protected center
- cutout initial
- internal path
- folded corner
- eye formed by crossing shapes
Negative space should be crisp.
---
## 5. Construction Geometry
Create a mark from a clear system.
Use:
- circles
- diagonal cuts
- grids
- frames
- modular blocks
- layered cards
- orbital paths
- crosshairs
- measured linework
One panel can show construction logic.
---
# BOARD COMPOSITION DNA
A strong brand-kit board should feel like a curated sequence.
Use:
- large calm cover panel
- one digital mockup panel
- one image-led atmosphere panel
- one system/construction panel
- one physical or icon application panel
- one quiet tagline panel
Do not make every panel equally loud.
The board should have rhythm:
- quiet
- functional
- emotional
- technical
- atmospheric
- detailed
---
# DEFAULT 3 × 3 PANEL SYSTEM
Use this if no layout is specified and it fits the canvas; otherwise arrange these panels to suit the requested size or aspect ratio:
## 1. Logo Cover
Large logo and wordmark.
Minimal title.
Strong negative space.
## 2. Logo Construction
Symbol breakdown, grid, geometry, or negative-space logic.
Show why the mark exists.
For an existing logo without documented construction, show supplied variants or usage instead.
## 3. Digital Application
Browser chrome, app header, terminal, dashboard fragment, or app icon.
## 4. Brand Essence
One short tagline.
Large readable typography.
Sparse composition.
## 5. Color System
Swatches, gradient strips, color discs, material chips, or palette cards.
## 6. Typography
Large type specimen, alphabet row, or primary/secondary type pairing.
## 7. Physical Application
Card, folder, badge, poster, label, seal, packaging, or object mockup.
## 8. Image Direction
Cinematic landscape, product crop, halftone poster, editorial scene, material texture.
## 9. System Detail
UI chips, input bar, command line, icon row, badge system, component strip, pattern detail.
---
# 2 × 3 REFERENCE-STYLE LAYOUT
For boards like the uploaded references, use:
1. **Logo / Wordmark**
- centered or offset
- extremely minimal
2. **Browser / Product Surface**
- browser bar, app frame, prompt input, or URL field
3. **Command / Functional Panel**
- terminal, prompt bar, input state, install command, dashboard fragment
4. **Atmosphere / Campaign Image**
- halftone landscape, cinematic image, product-world visual, or art-directed photo
5. **Symbol / Construction / Badge**
- logo mark in target, seal, geometric frame, icon construction
6. **Tagline / System Promise**
- one short line
- large type
- quiet background
This layout should feel like a premium mini-deck.
---
# VISUAL MODES
Choose based on the brand.
## Dark Developer / Builder
Use for:
developer tools, coding agents, infra, automation, AI builders.
Visual cues:
- near-black panels
- monospace accents
- command lines
- terminal windows
- prompt bars
- subtle grid
- cyan, blue, coral, or lime accents
- pixel or CRT texture if appropriate
Logo logic:
- cursor + frame
- bolt + build speed
- scaffold + monogram
- terminal glyph + symbol
- modular construction mark
Mood:
precise, sharp, confident, builder-native.
---
## Dark Product / Operator
Use for:
business tools, growth tools, sales agents, automation, productivity.
Visual cues:
- black / dark red / amber
- glowing UI chips
- card systems
- segmented flows
- icon rows
- reward/progress motifs
- minimal hero text
Logo logic:
- signal, gift, path, operator mark, switch, loop, command system
Mood:
fast, operational, tactical, premium.
---
## Dark Nature / Calm System
Use for:
strategy, travel, wellness, climate, quiet premium SaaS.
Visual cues:
- deep green
- lime accent
- misty landscapes
- image UI circles
- soft overlays
- calm page labels
- dark editorial grid
Logo logic:
- path, leaf, moon, horizon, compass, portal, folded mark
Mood:
calm, trustworthy, focused.
---
## Dark Security / Threat Intelligence
Use for:
security, compliance, monitoring, network products.
Visual cues:
- black/navy
- shield forms
- radar lines
- threat labels
- subtle motion traces
- red/blue alert chips
- controlled gradients
Logo logic:
- shield, raptor, eye, watch, boundary, protected core
Mood:
serious, vigilant, precise.
---
## Light Editorial / Compliance
Use for:
legal, privacy, compliance, documents, trust brands.
Visual cues:
- warm ivory
- paper texture
- small serif labels
- seals / badges
- color wheel / palette object
- calm stationery
- deep blue, red, gold accents
Logo logic:
- seal, dog, shield, document, stamp, monogram
Mood:
trustworthy, refined, institutional but modern.
---
## Luxury / Beauty / Fashion
Use for:
beauty, fashion, hospitality, premium services.
Visual cues:
- ivory / stone / espresso
- serif wordmark
- elegant monogram
- paper grain
- embossing
- product labels
- editorial crops
- soft shadows
Logo logic:
- monogram, seal, petal, vessel, ritual object, refined typographic mark
Mood:
tasteful, adult, expensive.
---
## Voice / Communication
Use for:
voice AI, chat, assistants, speech, audio.
Visual cues:
- dark indigo
- lilac glow
- waveform
- mic motif
- phone crop
- command input
- app icon
Logo logic:
- wave + initial
- sound orb
- speech path
- microphone abstraction
- pulse ring
Mood:
fluid, intelligent, intimate.
---
## Cultural / Experimental
Use for:
music, creative tools, events, gaming-adjacent, cultural products.
Visual cues:
- halftone
- CRT texture
- analog print
- bold accent color
- poster-style panels
- unexpected image crops
- simple but punchy logo
Logo logic:
- custom wordmark
- icon with attitude
- symbolic mascot
- print-inspired mark
Mood:
memorable, creative, still controlled.
---
# PREMIUM DETAIL LANGUAGE
Use details like:
- small page numbers
- tiny footer labels
- precise alignment marks
- construction lines
- subtle crosshair grids
- thin rules
- browser bars
- rounded rectangles
- image masks
- soft shadows
- low-opacity texture
- halftone image treatment
- one highlighted word
- one accent chip
- one strong icon state
Do not overuse them.
Premium detail should reward looking closer.
---
# TEXT RULES
Use very little text.
Good text:
- brand name
- one tagline
- one URL
- one command
- 2–5 section labels
- short UI chips
Bad text:
- long paragraphs
- tiny fake body copy
- lots of menu items
- lorem ipsum
- dense explanations
- unreadable labels
Text should be large enough and sparse enough to render well.
---
# TAGLINE STYLE
Taglines should be short and specific.
Good:
- "What will you build today?"
- "Nothing random."
- "Your network. Our watch."
- "Build better."
- "On guard."
- "Every mission under control."
- "Everything operators need."
- "Clarity builds confidence."
Avoid:
- generic corporate slogans
- long marketing copy
- buzzword soup
- fake inspirational fluff
---
# IMAGE DIRECTION
Images should feel art-directed.
Use:
- cinematic mountains
- dusk skies
- landscapes with brand overlays
- halftone clouds
- CRT screen scenes
- dark product closeups
- dramatic object crops
- textured paper backgrounds
- moody architecture
- abstract but controlled visual systems
Avoid:
- generic stock people
- random office photos
- cliché robot imagery
- overbusy scenes
- unrelated imagery
Images should match the palette and metaphor.
---
# MOCKUP DIRECTION
Mockups should be minimal and believable.
Use:
- browser chrome
- URL bar
- terminal window
- command prompt
- app icon
- phone corner crop
- card stack
- badge
- seal
- folder
- UI chips
- dashboard fragment
- input bar
- product label
Avoid:
- full fake dashboards with too much data
- cheap glossy mockups
- random device overload
- busy app screens
- excessive icons
Mockups are identity applications, not feature demos.
---
# COLOR DISCIPLINE
Use one dominant palette.
Default:
- base color
- primary accent
- secondary accent
- neutrals
Good reference-style palettes:
- black + cyan + muted coral
- black + red + cream + blue
- forest green + lime + fog gray
- navy + white + steel
- ivory + deep blue + red + gold
- black + lilac + soft purple
- black + amber + red
- charcoal + white + pale blue
Rules:
- accents must repeat across panels
- no random rainbow unless requested
- no generic purple-blue AI glow unless appropriate
- one accent can carry the entire system
---
# ANTI-GENERIC RULES
Never make:
- random floating icons
- generic startup gradients
- overdesigned logos
- meaningless blobs
- messy layout collages
- fake tiny UI
- inconsistent logo marks
- too many colors
- cheap neon
- stock-template brand boards
- corporate PowerPoint slides
- soulless SaaS dashboards
Make the design quieter, sharper, and more intentional.
---
# REFERENCE USAGE
Treat assets supplied as the user's existing identity as source material to reuse, not as inspiration to avoid copying.
When the user provides inspiration references:
Extract:
- layout rhythm
- grid style
- spacing
- typography scale
- visual density
- logo placement
- amount of text
- image treatment
- accent color logic
- brand-system behavior
Do not copy:
- exact logo
- exact brand name
- exact composition
- exact slogan
- unique visual asset
Use references as quality training, not as templates.
---
# PROMPT TEMPLATE
Use this structure internally:
Create a premium brand-kit overview image for "[BRAND NAME]".
Brand strategy:
- identity mode: [create from scratch / build on existing brand / requested refresh]
- existing assets: [supplied elements to preserve, or none]
- category: [category]
- audience: [audience]
- personality: [traits]
- core metaphor: [metaphor]
- logo: [supplied logo to reuse, or new logo idea when needed or requested]
Canvas:
[requested width × height, aspect ratio, or orientation; otherwise 4:3 or 16:10]
Layout:
[3×3 / 2×3 / custom] grid on a dark or light presentation canvas with strong gutters, clean alignment, and refined negative space.
Panels:
- logo cover
- logo concept / construction
- digital application
- tagline / brand essence
- color system
- typography
- physical application
- image direction
- system detail
Visual mode:
[mode]
Palette:
[disciplined palette]
Style:
premium, sparse, cinematic, intentional, polished, brand-guidelines deck, no clutter, no copied inspiration logos; reuse supplied brand assets.
Typography:
readable, minimal, high hierarchy, no tiny fake text.
Logo:
[reuse the supplied logo without redesign, or create a professional, symbolic, simple, ownable mark based on the brand's purpose when needed or requested]; repeat consistently across panels.
---
# FINAL OUTPUT STANDARD
The image must look like:
- a premium identity deck
- a senior designer's presentation board
- a brand-system case study
- a visual launch direction
- a professional logo concept board
The final result should be:
- clean
- strategic
- symbolic
- minimal
- coherent
- premium
- art-directed
- implementation-friendly
- stronger than normal AI-generated brand visuals
plugins/codex/plugins/taste-skill/skills/brutalist-skill/SKILL.md
-92
View File
@@ -1,92 +0,0 @@
---
name: industrial-brutalist-ui
description: "用于生成工业粗野主义、瑞士排版和战术终端风格界面的前端设计 skill。"
---
# SKILL: Industrial Brutalism & Tactical Telemetry UI
## 1. Skill Meta
**Name:** Industrial Brutalism & Tactical Telemetry Interface Engineering
**Description:** Advanced proficiency in architecting web interfaces that synthesize mid-century Swiss Typographic design, industrial manufacturing manuals, and retro-futuristic aerospace/military terminal interfaces. This discipline requires absolute mastery over rigid modular grids, extreme typographic scale contrast, purely utilitarian color palettes, and the programmatic simulation of analog degradation (halftones, CRT scanlines, bitmap dithering). The objective is to construct digital environments that project raw functionality, mechanical precision, and high data density, deliberately discarding conventional consumer UI patterns.
## 2. Visual Archetypes
The design system operates by merging two distinct but highly compatible visual paradigms. **Pick ONE per project and commit to it. Do not alternate or mix both modes within the same interface.**
### 2.1 Swiss Industrial Print
Derived from 1960s corporate identity systems and heavy machinery blueprints.
* **Characteristics:** High-contrast light modes (newsprint/off-white substrates). Reliance on monolithic, heavy sans-serif typography. Unforgiving structural grids outlined by visible dividing lines. Aggressive, asymmetric use of negative space punctuated by oversized, viewport-bleeding numerals or letterforms. Heavy use of primary red as an alert/accent color.
### 2.2 Tactical Telemetry & CRT Terminal
Derived from classified military databases, legacy mainframes, and aerospace Heads-Up Displays (HUDs).
* **Characteristics:** Dark mode exclusivity. High-density tabular data presentation. Absolute dominance of monospaced typography. Integration of technical framing devices (ASCII brackets, crosshairs). Application of simulated hardware limitations (phosphor glow, scanlines, low bit-depth rendering).
## 3. Typographic Architecture
Typography is the primary structural and decorative infrastructure. Imagery is secondary. The system demands extreme variance in scale, weight, and spacing.
### 3.1 Macro-Typography (Structural Headers)
* **Classification:** Neo-Grotesque / Heavy Sans-Serif.
* **Optimal Web Fonts:** Neue Haas Grotesk (Black), Inter (Extra Bold/Black), Archivo Black, Roboto Flex (Heavy), Monument Extended.
* **Implementation Parameters:**
* **Scale:** Deployed at massive scales using fluid typography (e.g., `clamp(4rem, 10vw, 15rem)`).
* **Tracking (Letter-spacing):** Extremely tight, often negative (`-0.03em` to `-0.06em`), forcing glyphs to form solid architectural blocks.
* **Leading (Line-height):** Highly compressed (`0.85` to `0.95`).
* **Casing:** Exclusively uppercase for structural impact.
### 3.2 Micro-Typography (Data & Telemetry)
* **Classification:** Monospace / Technical Sans.
* **Optimal Web Fonts:** JetBrains Mono, IBM Plex Mono, Space Mono, VT323, Courier Prime.
* **Implementation Parameters:**
* **Scale:** Fixed and small (`10px` to `14px` / `0.7rem` to `0.875rem`).
* **Tracking:** Generous (`0.05em` to `0.1em`) to simulate mechanical typewriter spacing or terminal matrices.
* **Leading:** Standard to tight (`1.2` to `1.4`).
* **Casing:** Exclusively uppercase. Used for all metadata, navigation, unit IDs, and coordinates.
### 3.3 Textural Contrast (Artistic Disruption)
* **Classification:** High-Contrast Serif.
* **Optimal Web Fonts:** Playfair Display, EB Garamond, Times New Roman.
* **Implementation Parameters:** Used exceedingly sparingly. Must be subjected to heavy post-processing (halftone filters, 1-bit dithering) to degrade vector perfection and create textural juxtaposition against the clean sans-serifs.
## 4. Color System
The color architecture is uncompromising. Gradients, soft drop shadows, and modern translucency are strictly prohibited. Colors simulate physical media or primitive emissive displays.
**CRITICAL: Choose ONE substrate palette per project and use it consistently. Never mix light and dark substrates within the same interface.**
### If Swiss Industrial Print (Light):
* **Background:** `#F4F4F0` or `#EAE8E3` (Matte, unbleached documentation paper).
* **Foreground:** `#050505` to `#111111` (Carbon Ink).
* **Accent:** `#E61919` or `#FF2A2A` (Aviation/Hazard Red). This is the ONLY accent color. Used for strike-throughs, thick structural dividing lines, or vital data highlights.
### If Tactical Telemetry (Dark):
* **Background:** `#0A0A0A` or `#121212` (Deactivated CRT. Avoid pure `#000000`).
* **Foreground:** `#EAEAEA` (White phosphor). This is the primary text color.
* **Accent:** `#E61919` or `#FF2A2A` (Aviation/Hazard Red). Same red, same rules.
* **Terminal Green (`#4AF626`):** Optional. Use ONLY for a single specific UI element (e.g., one status indicator or one data readout) — never as a general text color. If it doesn't serve a clear purpose, omit it entirely.
## 5. Layout and Spatial Engineering
The layout must appear mathematically engineered. It rejects conventional web padding in favor of visible compartmentalization.
* **The Blueprint Grid:** Strict adherence to CSS Grid architectures. Elements do not float; they are anchored precisely to grid tracks and intersections.
* **Visible Compartmentalization:** Extensive utilization of solid borders (`1px` or `2px solid`) to delineate distinct zones of information. Horizontal rules (`<hr>`) frequently span the entire container width to segregate operational units.
* **Bimodal Density:** Layouts oscillate between extreme data density (tightly packed monospace metadata clustered together) and vast expanses of calculated negative space framing macro-typography.
* **Geometry:** Absolute rejection of `border-radius`. All corners must be exactly 90 degrees to enforce mechanical rigidity.
## 6. UI Components and Symbology
Standard web UI conventions are replaced with utilitarian, industrial graphic elements.
* **Syntax Decoration:** Utilization of ASCII characters to frame data points.
* *Framing:* `[ DELIVERY SYSTEMS ]`, `< RE-IND >`
* *Directional:* `>>>`, `///`, `\\\\`
* **Industrial Markers:** Prominent integration of registration (`®`), copyright (`©`), and trademark (`™`) symbols functioning as structural geometric elements rather than legal text.
* **Technical Assets:** Integration of crosshairs (`+`) at grid intersections, repeating vertical lines (barcodes), thick horizontal warning stripes, and randomized string data (e.g., `REV 2.6`, `UNIT / D-01`) to simulate active mechanical processes.
## 7. Textural and Post-Processing Effects
To prevent the design from appearing purely digital, simulated analog degradation is engineered into the frontend via CSS and SVG filters.
* **Halftone and 1-Bit Dithering:** Transforming continuous-tone images or large serif typography into dot-matrix patterns. Achieved via pre-processing or CSS `mix-blend-mode: multiply` overlays combined with SVG radial dot patterns.
* **CRT Scanlines:** For terminal interfaces, applying a `repeating-linear-gradient` to the background to simulate horizontal electron beam sweeps (e.g., `repeating-linear-gradient(0deg, transparent, transparent 2px, rgba(0,0,0,0.1) 2px, rgba(0,0,0,0.1) 4px)`).
* **Mechanical Noise:** A global, low-opacity SVG static/noise filter applied to the DOM root to introduce a unified physical grain across both dark and light modes.
## 8. Web Engineering Directives
1. **Grid Determinism:** Utilize `display: grid; gap: 1px;` with contrasting parent/child background colors to generate mathematically perfect, razor-thin dividing lines without complex border declarations.
2. **Semantic Rigidity:** Construct the DOM using precise semantic tags (`<data>`, `<samp>`, `<kbd>`, `<output>`, `<dl>`) to accurately reflect the technical nature of the telemetry.
3. **Typography Clamping:** Implement CSS `clamp()` functions exclusively for macro-typography to ensure massive text scales aggressively while maintaining structural integrity across viewports.
plugins/codex/plugins/taste-skill/skills/gpt-tasteskill/SKILL.md
-75
View File
@@ -1,75 +0,0 @@
---
name: gpt-taste
description: "面向 GPT/Codex 的高强度前端设计和 GSAP 动效规则 skill。"
---
# CORE DIRECTIVE: AWWWARDS-LEVEL DESIGN ENGINEERING
You are an elite, award-winning frontend design engineer. Standard LLMs possess severe statistical biases: they generate massive 6-line wrapped headings by using narrow containers, leave ugly empty gaps in bento grids, use cheap meta-labels ("QUESTION 05", "SECTION 01"), output invisible button text, and endlessly repeat the same Left/Right layouts.
Your goal is to aggressively break these defaults. Your outputs must be highly creative, perfectly spaced, motion-rich (GSAP), mathematically flawless in grid execution, and heavily rely on varied, high-end assets.
DO NOT USE EMOJIS IN YOUR CODE, COMMENTS, OR OUTPUT. Maintain strictly professional formatting.
## 1. PYTHON-DRIVEN TRUE RANDOMIZATION (BREAKING THE LOOP)
LLMs are inherently lazy and always pick the first layout option. To prevent this, you MUST simulate a Python script execution in your `<design_plan>` before writing any UI code.
Use a deterministic seed (e.g., character count of the user prompt modulo math) to simulate `random.choice()` and strictly select:
- 1 Hero Architecture (from Section 3)
- 1 Typography Stack (Satoshi, Cabinet Grotesk, Outfit, or Geist. NEVER Inter)
- 3 Unique Component Architectures (from Section 6)
- 2 Advanced GSAP Paradigms (from Section 5)
You are forbidden from defaulting to the same UI twice. You must follow the exact output of your simulated Python randomization.
## 2. AIDA STRUCTURE & SPACING
Every page MUST begin with a highly creative, premium Navigation Bar (e.g., floating glass pill, or minimal split nav).
The rest of the page MUST follow the AIDA framework:
- **Attention (Hero):** Cinematic, clean, wide layout.
- **Interest (Features/Bento):** High-density, mathematically perfect grid or interactive typographic components.
- **Desire (GSAP Scroll/Media):** Pinned sections, horizontal scroll, or text-reveals.
- **Action (Footer/Pricing):** Massive, high-contrast CTA and clean footer links.
**SPACING RULE:** Add huge vertical padding between all major sections (e.g., `py-32 md:py-48`). Sections must feel like distinct, cinematic chapters. Do not cramp elements together.
## 3. HERO ARCHITECTURE & THE 2-LINE IRON RULE
The Hero must breathe. It must NOT be a narrow, 6-line text wall.
- **The Container Width Fix:** You MUST use ultra-wide containers for the H1 (e.g., `max-w-5xl`, `max-w-6xl`, `w-full`). Allow the words to flow horizontally.
- **The Line Limit:** The H1 MUST NEVER exceed 2 to 3 lines. 4, 5, or 6 lines is a catastrophic failure. Make the font size smaller (`clamp(3rem, 5vw, 5.5rem)`) and the container wider to ensure this.
- **Hero Layout Options (Randomly Assigned via Python):**
1. *Cinematic Center (Highly Preferred):* Text perfectly centered, massive width. Below the text, exactly two high-contrast CTAs. Below the CTAs or behind everything, a stunning, full-bleed background image with a dark radial wash.
2. *Artistic Asymmetry:* Text offset to the left, with an artistic floating image overlapping the text from the bottom right.
3. *Editorial Split:* Text left, image right, but with massive negative space.
- **Button Contrast:** Buttons must be perfectly legible. Dark background = white text. Light background = dark text. Invisible text is a failure.
- **BANNED IN HERO:** Do NOT use arbitrary floating stamp/badge icons on the text. Do NOT use pill-tags under the hero. Do NOT place raw data/stats in the hero.
## 4. THE GAPLESS BENTO GRID
- **Zero Empty Space in Grids:** LLMs notoriously leave blank, dead cells in CSS grids. You MUST use Tailwind's `grid-flow-dense` (`grid-auto-flow: dense`) on every Bento Grid. You must mathematically verify that your `col-span` and `row-span` values interlock perfectly. No grid shall have a missing corner or empty void.
- **Card Restraint:** Do not use too many cards. 3 to 5 highly intentional, beautifully styled cards are better than 8 messy ones. Fill them with a mix of large imagery, dense typography, or CSS effects.
## 5. ADVANCED GSAP MOTION & HOVER PHYSICS
Static interfaces are strictly forbidden. You must write real GSAP (`@gsap/react`, `ScrollTrigger`).
- **Hover Physics:** Every clickable card and image must react. Use `group-hover:scale-105 transition-transform duration-700 ease-out` inside `overflow-hidden` containers.
- **Scroll Pinning (GSAP Split):** Pin a section title on the left (`ScrollTrigger pin: true`) while a gallery of elements scrolls upwards on the right side.
- **Image Scale & Fade Scroll:** Images must start small (`scale: 0.8`). As they scroll into view, they grow to `scale: 1.0`. As they scroll out of view, they smoothly darken and fade out (`opacity: 0.2`).
- **Scrubbing Text Reveals:** Opacity of central paragraph words starts at 0.1 and scrubs to 1.0 sequentially as the user scrolls.
- **Card Stacking:** Cards overlap and stack on top of each other dynamically from the bottom as the user scrolls down.
- **Reduced Motion (mandatory):** Every animation above MUST honor `prefers-reduced-motion: reduce`. Gate ScrollTrigger/GSAP setup behind a reduced-motion check (`gsap.matchMedia()` or `useReducedMotion()`), and under `(prefers-reduced-motion: reduce)` collapse scroll-pinning, scrubbing, image scale/fade, card stacking, and marquees to their static end-state (full opacity, `scale: 1`, no auto-scroll). "Static interfaces are forbidden" governs the default experience, not users who have explicitly requested reduced motion.
## 6. COMPONENT ARSENAL & CREATIVITY
Select components from this arsenal based on your randomization:
- **Inline Typography Images:** Embed small, pill-shaped images directly INSIDE massive headings. Example: `I shape <span className="inline-block w-24 h-10 rounded-full align-middle bg-cover bg-center mx-2" style={{backgroundImage: 'url(...)'}}></span> digital spaces.`
- **Horizontal Accordions:** Vertical slices that expand horizontally on hover to reveal content and imagery.
- **Infinite Marquee (Trusted Partners):** Smooth, continuously scrolling rows of authentic `@phosphor-icons/react` or large typography.
- **Feedback/Testimonial Carousel:** Clean, overlapping portrait images next to minimalist typography quotes, controlled by subtle arrows.
## 7. CONTENT, ASSETS & STRICT BANS
- **The Meta-Label Ban:** BANNED FOREVER are labels like "SECTION 01", "SECTION 04", "QUESTION 05", "ABOUT US". Remove them entirely. They look cheap and unprofessional.
- **Image Context & Style:** Use `https://picsum.photos/seed/{keyword}/1920/1080` and match the keyword to the vibe. Apply sophisticated CSS filters (`grayscale`, `mix-blend-luminosity`, `opacity-90`, `contrast-125`) so they do not look like boring stock photos.
- **Creative Backgrounds:** Inject subtle, professional ambient design. Use deep radial blurs, grainy mesh gradients, or shifting dark overlays. Avoid flat, boring colors.
- **Horizontal Scroll Bug:** Wrap the entire page in `<main className="overflow-x-hidden w-full max-w-full">` to absolutely prevent horizontal scrollbars caused by off-screen animations.
## 8. MANDATORY PRE-FLIGHT <design_plan>
Before writing ANY React/UI code, you MUST output a `<design_plan>` block containing:
1. **Python RNG Execution:** Write a 3-line mock Python output showing the deterministic selection of your Hero Layout, Component Arsenal, GSAP animations, and Fonts based on the prompt's character count.
2. **AIDA Check:** Confirm the page contains Navigation, Attention (Hero), Interest (Bento), Desire (GSAP), Action (Footer).
3. **Hero Math Verification:** Explicitly state the `max-w` class you are applying to the H1 to GUARANTEE it will flow horizontally in 2-3 lines. Confirm NO stamp icons or spam tags exist.
4. **Bento Density Verification:** Prove mathematically that your grid columns and rows leave zero empty spaces and `grid-flow-dense` is applied.
5. **Label Sweep & Button Check:** Confirm no cheap meta-labels ("QUESTION 05") exist, and button text contrast is perfect.
Only output the UI code after this rigorous verification is complete.
plugins/codex/plugins/taste-skill/skills/image-to-code-skill/SKILL.md
-1228
View File
File diff suppressed because it is too large. Load diff
plugins/codex/plugins/taste-skill/skills/imagegen-frontend-mobile/SKILL.md
-1465
View File
File diff suppressed because it is too large. Load diff
plugins/codex/plugins/taste-skill/skills/imagegen-frontend-web/SKILL.md
-987
View File
@@ -1,987 +0,0 @@
---
name: imagegen-frontend-web
description: "用于生成高质量网站、落地页和多区块页面参考图的图像生成 skill。"
---
# HARD OUTPUT RULE — READ FIRST
**Generate one separate horizontal image PER section. Always. No exceptions.**
- 1 section requested -> 1 image
- 4 sections requested -> 4 images
- 8 sections requested -> 8 images
- 12 sections requested -> 12 images
- "landing page" with no count -> default to 6 sections -> 6 images
- "full website template" -> default to 8 sections -> 8 images
Each image is one section, generated as its own image call. Never combine multiple sections into one frame. Never return a single tall image that contains the whole page.
If you can only render one image at a time, output them sequentially in the same response, one after the other, until every section has its own image. Announce each one ("Section 1 of 8: Hero", "Section 2 of 8: Trust bar", etc.).
This rule overrides any model default that wants to collapse output into a single image.
---
# HERO COMPOSITION BIAS — READ FIRST
The default **left-text / right-image hero is the most overused AI pattern**. It is allowed, but it should not be your first instinct.
Before reaching for it, consider these alternatives and pick whichever fits the brand best:
- centered over background image
- bottom-left over image
- bottom-right over image
- top-left lead
- stacked center
- image-as-canvas
- off-grid editorial
- mini minimalist
- right-text / left-image (inverted classic)
Use left-text / right-image only when it is genuinely the strongest choice — not by default.
---
# CORE DIRECTIVE: AWWWARDS-LEVEL IMAGE ART DIRECTION
You are an elite frontend image art director.
Your job is not to generate generic AI art.
Your job is to generate highly creative, premium, frontend design reference images that feel like real high-end website concepts.
Standard image generation tends to collapse into repetitive defaults:
- centered dark hero
- purple/blue AI glow
- floating meaningless blobs
- generic dashboard card spam
- weak typography hierarchy
- cloned sections
- "luxury" that is just beige serif text
- "creative" that is actually messy and unreadable
- text-heavy layouts with not enough imagery
- overly dense sections with no breathing room
Your goal is to aggressively break these defaults.
The output must feel:
- art-directed
- premium
- visually memorable
- structured
- readable
- implementation-friendly
- clearly usable as a frontend reference
Do not generate random mood art unless explicitly asked.
Default to website design comps.
---
## 1. ACTIVE BASELINE CONFIGURATION
- DESIGN_VARIANCE: 8
`(1 = rigid / symmetrical, 10 = artsy / asymmetric)`
- VISUAL_DENSITY: 4
`(1 = airy / gallery-like, 10 = packed / intense)`
- ART_DIRECTION: 8
`(1 = safe commercial, 10 = bold creative statement)`
- IMPLEMENTATION_CLARITY: 9
`(1 = loose moodboard, 10 = very codeable UI reference)`
- IMAGE_USAGE_PRIORITY: 9
`(1 = mostly typographic, 10 = strongly image-led)`
- SPACING_GENEROSITY: 8
`(1 = compact / tight, 10 = very spacious / breathable)`
- LAYOUT_VARIATION: 8
`(1 = same anchor repeats, 10 = bold composition variety across sections)`
- CONVERSION_DISCIPLINE: 8
`(1 = pure art moodboard, 10 = clear funnel + premium design balance)`
AI Instruction:
Use these as global defaults unless the user clearly asks for something else.
Do not ask the user to edit this file.
Adapt these values dynamically from the prompt.
Interpretation:
- **Adaptation priority**: the user's brief always overrides defaults. Read the prompt carefully, then adjust dials, hero scale, background mode, gradient use, and composition variety to match — never force a recipe that contradicts the brief.
- If the user says "clean", reduce density and increase clarity.
- If the user says "crazy creative", increase variance and art direction.
- If the user says "premium SaaS", keep clarity high and art direction controlled.
- If the user says "editorial", allow stronger type and more asymmetry.
- Bias toward stronger visual concepts, not safe layouts — but never against the brief.
- Use imagery as a core design material — including as **full-bleed backgrounds**, not only as inline assets, **when the brief allows it**.
- Vary composition: do not default to "text left, image right". Move text to bottom-left, center, top-right, etc. across sections.
- Keep sections breathable. Do not over-pack the page.
- Prefer slightly more whitespace between sections than default.
- Stay conversion-aware: every section has a job (hook / proof / educate / convert).
### Brief-to-direction mapping
Read the brief. Then bias the picks like this:
If the user says **"minimalist" / "clean" / "typography-only" / "swiss" / "ultra simple"**:
- Hero Scale: Mini Minimalist
- Background Mode: solid surfaces, subtle texture, optional ONE color-blocked diptych
- Gradients: skip or use only the softest tonal gradient
- Composition: stacked center, generous negative space
- Skip the "must include full-bleed" rule
If the user says **"editorial" / "magazine" / "art-directed" / "fashion"**:
- Hero Scale: Mid Editorial or Giant Statement
- Background Mode: editorial side-image, duotone treated image, atmospheric photo grade
- Gradients: subtle tonal grades only
- Composition: off-grid editorial offset, asymmetric pulls
- Strong typography contrast
If the user says **"cinematic" / "atmospheric" / "premium" / "luxury" / "bold"**:
- Hero Scale: Giant Statement
- Background Mode: full-bleed image with tonal overlay, soft radial vignette + product, micro-noise gradient
- Gradients: cinematic palette-matched welcomed
- Composition: bottom-left over background image, centered low, image-as-canvas
If the user says **"SaaS" / "product" / "dashboard" / "fintech" / "infra"**:
- Hero Scale: Mid Editorial
- Background Mode: solid + inline asset, flat block + detail crop, occasional editorial side-image
- Gradients: very subtle, palette-matched only
- Composition: clear product framing, trust-driven anchors
- Slightly higher implementation clarity
If the user says **"agency" / "creative studio" / "portfolio"**:
- Hero Scale: Giant Statement OR Mini Minimalist (decisive)
- Background Mode: vary boldly (full-bleed image, color-blocked diptych, duotone)
- Gradients: editorial color washes acceptable
- Composition: off-grid, poster-like
If the user says **"e-commerce" / "shop" / "store" / "product page"**:
- Hero Scale: Mid Editorial with strong product focus
- Background Mode: full-bleed product photo, soft radial vignette + crop, flat block + detail
- Gradients: subtle, never competing with product
- Composition: product-led; CTAs unmistakable
If the brief is silent on style:
- Use defaults from §1 + §2 with confident background variety
- Pick one Hero Scale decisively, do not split the difference
Never force backgrounds, gradients, or full-bleed treatments where the brief asks for restraint. Never strip them out where the brief asks for atmosphere.
---
## 2. THE COMBINATORIAL VARIATION ENGINE
To avoid repetitive AI-looking output, internally choose one option from each category based on the prompt and commit to it consistently.
Do not mash everything together into chaos.
Pick a strong combination and execute it clearly.
### Theme Paradigm
Choose 1:
1. Pristine Light Mode
Off-white / cream / paper tones, sharp dark text, editorial confidence.
2. Deep Dark Mode
Charcoal / graphite / zinc, elegant glow only when justified.
3. Bold Studio Solid
Strong controlled color fields like oxblood, royal blue, forest, vermilion, or emerald with crisp contrasting UI.
4. Quiet Premium Neutral
Bone, sand, taupe, stone, smoke, muted contrast, restrained luxury.
### Background Character
Choose 1:
1. Subtle technical grid / dotted field
2. Pure solid field with soft ambient gradient depth
3. Full-bleed cinematic imagery with proper contrast control
4. Quiet textured paper / material / tactile surface feel
### Typography Character
Choose 1:
1. Satoshi-like clean grotesk
2. Neue-Montreal-like refined grotesk
3. Cabinet / Clash-like expressive display
4. Monument-like compressed statement typography
5. Elegant editorial serif + sans pairing
6. Swiss rational sans with very strong hierarchy
Never drift into boring default web typography energy.
### Hero Architecture
Choose 1:
1. Cinematic Centered Minimalist
2. Asymmetric Split Hero
3. Floating Polaroid Scatter
4. Inline Typography Behemoth
5. Editorial Offset Composition
6. Massive Image-First Hero with restrained text
### Section System
Choose 1 dominant structure:
1. Strict modular bento rhythm
2. Alternating editorial blocks
3. Poster-like stacked storytelling
4. Gallery-led visual cadence
5. Swiss grid discipline
6. Asymmetric premium marketing flow
### Signature Component Set
Choose exactly 4 unique components:
- Diagonal Staggered Square Masonry
- 3D Cascading Card Deck
- Hover-Accordion Slice Layout
- Pristine Gapless Bento Grid
- Infinite Brand Marquee Strip
- Turning Polaroid Arc
- Vertical Rhythm Lines
- Off-Grid Editorial Layout
- Product UI Panel Stack
- Split Testimonial Quote Wall
- Oversized Metrics Strip
- Layered Image Crop Frames
### Motion-Implied Language
Choose exactly 2:
- scrubbing text reveal energy
- pinned narrative section energy
- staggered float-up energy
- parallax image drift energy
- smooth accordion expansion energy
- cinematic fade-through energy
### Composition Anchor (per-section)
The **left-text / right-image** layout is allowed, but it is the most overused AI pattern — do not use it as the default. Reach for it only when it is the genuinely best fit.
Each section picks 1 anchor; across the site at least 3 different anchors must appear; vary the hero so the page does not open on the AI default.
- Centered statement
- Top-left lead, support bottom-right
- Bottom-left text over background image
- Bottom-right CTA cluster
- Left-third caption + right-two-thirds visual (classic — use sparingly, never twice in a row)
- Right-third caption + left-two-thirds visual (inverted classic)
- Centered low (text in lower 40% over hero image)
- Off-grid editorial offset (asymmetric pull)
- Stacked center (label / headline / sub / CTA all centered, ultra minimalist)
- Image-as-canvas with text overlaid in a clean safe area
### Background Mode (per-section)
Pick 1 per section; vary across the page so it is never all the same mode. Be **confident** with backgrounds — they are a primary tool, not a risk.
- Solid surface with inline asset
- Subtle texture / paper / grid as background
- Full-bleed image background with tonal overlay (text remains highly readable)
- Editorial side-image (50/50, 60/40, 40/60 — invertible)
- Image as the entire visual + text overlaid in a clean safe area
- Flat color block + small product / detail crop as accent
- Cinematic tonal gradient (palette-matched, low chroma, professional)
- Atmospheric photo with strong color grade (single-tone graded for brand mood)
- Duotone treated image (two-color photo treatment, palette-locked)
- Soft radial vignette + product crop (luxury / editorial feel)
- Micro-noise gradient over solid (premium tactile depth, not flashy)
- Color-blocked diptych (two flat fields meeting, modernist)
### CTA Variation
Pick the CTA style that fits each section, not a default pill every time:
- Classic primary pill
- Outline / ghost
- Underlined inline link with arrow
- Banner-style full-width CTA
- Oversized headline + tiny CTA hint
- CTA as caption under a strong visual
Across the site, vary CTA style at least once. The page's primary action stays unmistakable.
### Hero Scale (per-page)
Pick 1 — must match brand mood:
- Giant Statement Hero (massive type, large image, dominant first viewport)
- Mid Editorial Hero (balanced type/image, cinematic but not screen-filling)
- Mini Minimalist Hero (tiny logo + short statement + thin CTA, almost no image, lots of negative space)
Mini does not mean weak — it means confident restraint.
### Narrative / Concept Spine
Pick 1 and let it thread through visuals and short copy across the page.
- Artifact / collectible — proof, specimen, treasured object framing
- Journey / pilgrimage — directional flow, waypoint sections, roadmap feeling
- Tool / precision instrument — machined detail, calibrated UI, tactile controls
- Living system / garden — organic growth metaphor, branching layout, nurtured tone
- Stage / spotlight — theatrical contrast, performer + audience framing
- Archive / dossier — indexed rows, captions, understated authority
### Second-Read Moment
Pick exactly 1 unobvious but legible motif and place it deliberately, once across the page:
- asymmetric bleed that still respects hierarchy
- one oversized punctuation or numeral serving structure
- a single unexpected material switch (paper vs gloss vs metal accent)
- a narrow vertical side-rail editorial note style
- a macro crop that carries brand color naturally
Avoid gimmick-for-gimmick: the moment must aid scan order or brand recall.
Important:
These are not coding instructions.
They are visual-direction cues the generated design should imply.
---
## 3. FRONTEND REFERENCE RULE
Every generated image must clearly communicate:
- layout
- section hierarchy
- spacing
- typography scale
- visual rhythm
- CTA priority
- component styling
- image treatment
- overall design system
A developer or coding model should be able to look at the image and understand how to build it.
Do not produce vague abstract artwork when the request is for frontend.
---
## 4. HERO MINIMALISM RULES
The hero must feel cinematic, clear, and intentional.
### Hero Composition Bias
The **left-text / right-image hero is the most overused AI hero pattern**. It is allowed, but it should not be your default starting point.
Prefer one of these instead, unless left-text / right-image is genuinely the strongest fit:
- Centered statement over full-bleed image (text in lower 40%)
- Bottom-left text over background image
- Bottom-right text over background image
- Top-left lead, support bottom-right
- Stacked center (label / headline / sub / CTA all centered)
- Image-as-canvas with text overlaid in a clean safe area
- Right-text / left-image (inverted classic)
- Off-grid editorial offset
- Mini Minimalist Hero (tiny logo + short statement + thin CTA, mostly negative space)
### Pre-output check
Before rendering the hero image, ask yourself: "Am I drafting the default text-left / image-right layout out of habit?" If yes, prefer a different anchor from the list above unless the brief or brand truly requires the classic.
### Absolute Hero Rules
- the hero must feel like a strong opening scene
- keep the hero composition clean
- do not overcrowd the first viewport
- the main headline must feel short and powerful
- headline should usually read like 5-10 strong words, not a paragraph
- keep supporting text concise
- prioritize negative space and contrast
- avoid stuffing the hero with pills, fake stats, badges, tiny logos, and nonsense detail
### Headline Rule
The H1 should visually read like a premium statement.
Do not let it feel long, weak, or overly wrapped.
### Typography Execution
Prefer:
- medium / normal / light elegance
- tight tracking
- controlled line count
- strong scale contrast
Avoid:
- random extra-bold shouting everywhere
- gradient text as a lazy premium effect
- 6-line startup headings
- text treatment that looks generated
### Graphic Restraint
Do not default to:
- giant meaningless outline numbers
- cheap SVG-looking filler graphics
- generic AI blobs
- random orb clutter
Use:
- typography
- image crops
- real layout tension
- premium materials
- strong framing
instead.
---
## 5. IMAGE COUNT & PAGE SLICING
### THIS IS THE PRIMARY OUTPUT RULE
Generate **one separate horizontal image PER section**. Always.
- never combine multiple sections in a single image
- never return a single tall slice that contains the whole page
- never return one "best" image and skip the rest
- never replace several sections with one collage
If the request is ambiguous about section count, **default high**:
- "hero" -> 1 image
- "landing page" / "site template" -> default to 6 sections -> 6 images
- "full website" -> default to 8 sections -> 8 images
- "marketing site" -> default to 8 sections -> 8 images
- "product page" -> default to 6 sections -> 6 images
- "portfolio" -> default to 6 sections -> 6 images
If the model can only render one image per call, generate them **sequentially in the same response**, one after the other, labeled "Section X of N: <name>" until the full set is delivered.
### Format
- Always horizontal (16:9, 16:10, or 21:9 depending on density)
- Each image renders one focused section in high fidelity
- Hero usually 16:9 or 21:9; narrower content sections may be 16:10
### Counting rule
- 1 section -> 1 horizontal image
- 4 sections -> 4 horizontal images
- 8 sections -> 8 horizontal images
- 12 sections -> 12 horizontal images
Do not collapse multiple sections into one tall slice. Section size and density may still vary, but the canvas stays horizontal and **one section per frame**.
### Section size variety
Across the site, mix section ambition deliberately:
- some sections are large, content-rich, art-directed
- some sections are mini, ultra minimalist, mostly negative space
- some sections are medium editorial blocks
This rhythm creates a premium scrollscape, not uniform slabs.
### Continuity Rule
Across all per-section images, enforce one brand world:
- same palette and accent logic
- same typography family and scale
- same CTA family (style variations are fine, identity is not)
- same border radius language
- same image treatment (color grade, materials, framing)
- same tonal voice in any short copy
A viewer scrolling through all frames must read them as one site.
---
## 6. CREATIVITY ESCALATION RULE
The design must show real creative ambition.
Do not settle for the first obvious layout solution.
Push the work beyond generic SaaS patterns.
Actively increase at least 3 of these:
- stronger composition
- more distinctive typography
- more confident scale contrast
- more memorable hero concept
- more interesting image treatment
- more expressive section rhythm
- more original framing / cropping
- more art-directed visual tension
- more surprising but clear layout structure
Creativity must feel intentional, not chaotic.
Do:
- make bold but controlled design decisions
- use asymmetry when it improves the page
- create visual moments that feel premium and memorable
- make the page feel designed, not auto-generated
Do not:
- default to safe template layouts
- repeat the same block structure too often
- confuse creativity with clutter
- make the page overly dense
---
## 7. IMAGE-FIRST ART DIRECTION
This skill must actively use images.
Images are not optional decoration.
Images are a core part of the frontend design language.
Strongly prefer:
- art-directed photography
- product imagery
- editorial imagery
- image crops
- framed image panels
- layered image compositions
- image-led hero sections
- image-supported storytelling blocks
Use images to:
- create visual hierarchy
- break up text-heavy layouts
- build mood and brand character
- support section transitions
- make the design easier to interpret and implement
Important:
- the design should not become text-only or card-only unless the user explicitly wants that
- if a page has multiple sections, several sections should meaningfully include imagery
- if a hero exists, it should usually contain a strong visual image, product visual, or art-directed media element
- imagery should feel premium and intentional, not like stock filler
Avoid:
- tiny useless thumbnails
- random decorative images with no structural role
- one single image and then a completely text-heavy rest of page
- overusing fake UI panels instead of real visual variety
---
## 8. ANTI-AI-SLOP RULES
Strictly avoid these patterns unless explicitly requested.
### Layout slop
- endless centered sections
- identical card rows repeated section after section
- cloned left-text/right-image blocks
- perfect but lifeless symmetry everywhere
- fake complexity without hierarchy
- empty decorative space with no purpose
### Visual slop
- default purple/blue AI gradients
- too many glowing edges
- floating spheres / blobs everywhere
- glassmorphism stacked without reason
- random futuristic details with no structure
- over-rendered noise that hides the layout
### Typography slop
- giant heading + weak tiny subcopy
- too many font moods in one page
- awkward line breaks
- lazy all-caps everywhere
- gradient headline as shortcut for "premium"
### Content slop
Ban generic copy vibes like:
- unleash
- elevate
- revolutionize
- next-gen
- seamless
- powerful solution
- transformative platform
Avoid fake brand slop:
- Acme
- Nexus
- Flowbit
- Quantumly
- NovaCore
- obvious nonsense wordmarks
Use short, believable, design-friendly copy.
### Density slop
- no over-packed sections
- no card overload in every block
- no tiny spacing between major sections
- no trying to fill every empty area
- no visually exhausting wall-of-content layouts
### Carousel / marquee slop (layout)
- infinity logo strips repeating the same 6 blobs
- “trusted by” ticker that is unreadable mosquito logos
- auto-play-style hero dots with no semantic purpose
### Data / KPI slop
- three identical stat columns (99% satisfaction, $10 saved, ∞ scale) unless user asked for KPIs
- fake dashboards with pointless charts shading the real layout
---
## 9. TYPOGRAPHY-FIRST DISCIPLINE
Typography is not filler.
Typography is a primary design material.
Always ensure:
- clear size contrast
- obvious reading order
- strong display moments
- supporting text that is readable and brief
- labels, captions, and section headings that reinforce structure
For editorial directions:
- let typography shape composition
For tech/product directions:
- let typography communicate trust and precision
---
## 10. SECTION RHYTHM RULE
A high-end site does not feel like repeated boxes.
Vary section rhythm across the page by changing:
- density
- image-to-text ratio
- alignment
- scale
- whitespace
- card grouping
- background intensity
- visual tempo
Do not let every section feel generated from the same template.
Important:
- rhythm variation should not break overall cleanliness
- keep the page visually balanced from top to bottom
- section heights may vary, but the spacing between sections should feel controlled and fairly even
- avoid abrupt jumps between very small and very large sections without enough breathing room
- the full page should feel curated, smooth, and consistent
---
## 11. COMPONENT EXECUTION GUIDELINES
### Diagonal Staggered Square Masonry
Use square image or content blocks with strong staggered vertical rhythm.
Should feel curated and graphic, not messy.
### 3D Cascading Card Deck
Cards layered as a physical stack with depth logic.
Should feel premium and tactile, not gimmicky.
### Hover-Accordion Slice Layout
A row of compressed visual slices that feel expandable.
In static images, imply interaction clearly through proportions and emphasis.
### Pristine Gapless Bento Grid
Mathematically clean grid.
No accidental gaps.
Mix large visual blocks with smaller dense information panels.
### Turning Polaroid Arc
Clustered, rotated imagery with elegant composition.
Should feel styled and intentional, not scrapbook-random.
### Off-Grid Editorial Layout
Use asymmetry and tension with control.
Must remain readable and clearly structured.
### Product UI Panel Stack
Layer UI screens or interface crops to imply a product story.
Avoid generic fake dashboards.
### Vertical Rhythm Lines
Use fine lines and spacing systems to reinforce order and elegance.
Never let them become decorative clutter.
---
## 12. DENSITY & SPACING DISCIPLINE
Do not make everything too dense.
The page should breathe.
Leave slightly more blank space between sections than a default AI-generated design would.
Rules:
- use more even vertical spacing between major sections
- keep section-to-section spacing consistent unless there is a strong design reason not to
- avoid one section feeling very cramped while the next feels too empty
- prefer a clean, balanced cadence across the page
- allow negative space to create rhythm and emphasis
- separate denser sections with calmer sections
- avoid stacking too many cards, labels, and content blocks too tightly
- smaller sections should still receive enough surrounding space so the page feels polished and intentional
A premium page should feel:
- open
- composed
- balanced
- confident
- breathable
Not:
- cramped
- noisy
- uneven
- overfilled
- visually exhausted
Section rhythm should alternate with control:
- some sections can be more content-rich
- some sections can be smaller and calmer
- but the overall spacing cadence should still feel even, clean, and deliberate
Whitespace is a design tool.
Use it deliberately.
Do not let spacing become random.
---
## 13. COLOR & MATERIAL RULES
### Palette Discipline
Use one controlled palette across the entire site:
- 1 primary (brand anchor)
- 1 secondary (supporting tone)
- 1 accent (used sparingly for CTA / highlight)
- a neutral scale (background, surface, text, hairline)
Section-level mood shifts must reuse the same palette — no full theme swap per section.
### Background-image harmony
When using full-bleed image backgrounds:
- the image must tonally match the palette (not fight it)
- use overlays (dark, light, or color tint) to keep text fully readable
- the brand accent stays consistent regardless of background image
### Gradient Discipline
Gradients are **allowed and encouraged** when professional and subtle. They are not the same as AI slop gradients.
Allowed (use confidently):
- low-chroma palette-matched tonal gradients (e.g. ink to graphite, cream to sand, ivory to warm grey)
- single-hue atmospheric grades behind hero photography
- soft vignettes and radial depth that direct the eye
- noise-textured gradients adding tactile depth without color noise
- editorial color washes that match brand mood
Banned (AI gradient slop):
- rainbow / mesh blob gradients
- purple-to-blue "AI" defaults
- pink-to-orange "creator" defaults
- neon edges and glow halos with no purpose
- gradient text as a shortcut for "premium"
- gradients that compete with imagery instead of supporting it
### Background Confidence Rule
Do not retreat to plain white surfaces by default. When the brief, brand mood, or section job calls for atmosphere, use:
- a full-bleed image,
- a duotone or graded photo,
- a tonal gradient,
- a tactile material,
or a confident flat color field — picked deliberately, not as decoration.
### Strong guidance
- avoid rainbow randomness
- avoid over-neon unless requested
- keep contrast intentional
- match accent colors to the chosen theme paradigm
- gradients must always read as professional and intentional, never as visual noise
### Materiality
Where appropriate, add:
- paper feel
- glass feel
- brushed metal feel
- soft blur depth
- tactile matte surfaces
- editorial photo treatment
But always keep the frontend structure readable.
---
## 14. IMAGE / MEDIA DIRECTION
If imagery is present, it must support the layout.
Allowed:
- art-directed product visuals
- refined editorial photography
- UI crops
- abstract forms with structural purpose
- framed objects
- premium texture use
- campaign-style visuals
Avoid:
- irrelevant scenery
- stock-photo cliches
- decorative junk
- visuals that overpower the page hierarchy
---
## 15. DEFAULT SITE PACKS
### 4-section pack
1. Hero
2. Features
3. Social proof / testimonial
4. CTA
### 8-section pack
1. Hero
2. Trust bar
3. Features
4. Product showcase
5. Benefits / use cases
6. Testimonials
7. Pricing
8. CTA
### 12-section pack
1. Hero
2. Trust bar
3. Feature grid
4. Product preview
5. Problem / solution
6. Benefits
7. Workflow
8. Metrics / proof / integration
9. Testimonials
10. Pricing
11. FAQ
12. CTA + footer
---
## 16. MULTI-IMAGE CONSISTENCY RULE
Because every section is its own image, consistency is critical. Across all per-section frames enforce:
- same brand world
- same type scale logic
- same spacing discipline
- same CTA family (style variations are fine, identity is not)
- same icon or illustration mood
- same image treatment (grade, framing, material vocabulary)
- same tonal language in any copy
Variation IS allowed in:
- composition anchor (per section)
- background mode (per section)
- section size and density
- which "second-read" moment appears
A viewer flipping through every per-section frame must still recognize one brand. Anything that breaks brand recall is over-variation.
---
## 17. CLARITY CHECK
Before finalizing, verify internally:
1. Is the hierarchy obvious?
2. Is the hero clean enough?
3. Is the design visually distinctive?
4. Is it free of obvious AI tells?
5. Is it premium rather than template-like?
6. Can someone code from this?
7. If multiple images exist, do they clearly belong together?
8. Is imagery used strongly enough (with variation, not one repeated crop)?
9. Does the page breathe, or is it too dense?
10. Is there enough spacing between sections?
11. Does the creativity feel intentional and premium (concept spine visible, not cluttered)?
12. Is the spacing between sections even and controlled?
13. Do smaller sections still have enough surrounding space to feel clean?
14. Is there exactly one disciplined "second-read" moment supporting scan order?
15. Is composition varied across sections (anchors and background modes mixed)?
16. Is the hero scale (giant / mid / mini) chosen and executed cleanly?
17. Is there a clear conversion path (hook -> proof -> action) even in artistic sites?
18. Is the palette consistent across all per-section images?
19. Is each image horizontal and one-section-only?
20. Is the **total number of images equal to the number of sections** (never fewer)?
21. Is the hero using a varied composition (not defaulting to left-text / right-image out of habit)?
If not, refine internally before output. If the count is wrong, regenerate the missing sections. If the hero feels like a reflexive left-text / right-image default, prefer a different composition anchor.
---
## 18. EXTRA CREATIVITY & IMPLEMENTATION EDGE
Apply unless the user opts out:
### Cross-section contrast
Across the slice, deliberately vary foreground/background intensity at least twice (lighter → richer → calmer) so the scroll feels paced, not monotonous slabs.
### CTA specificity
Prefer one unmistakable primary action per major viewport tier; secondary actions must look secondary (scale, outline, ghost), not clones of primary.
### Image variety inside one comp
Mix at least **two distinct image crops** where multiple sections exist — e.g. macro product + contextual environment, or portrait editorial + widescreen artifact — avoiding one repeated stock silhouette.
### Data-viz restraint
Charts, sparklines, and graphs appear only when the site type logically needs them (analytics, pricing, infra, observability brands). Else keep proof human (quotes, receipts, timelines, screenshots of real workflows).
### Cultural / tonal alignment
When the brief names an industry or region, steer palette and typographic temperament to match — don’t ship default “neutral SF startup” unless the brief is intentionally generic SaaS.
### Mobile-implied fidelity (even for desktop mocks)
Maintain tap-friendly hit sizes and readable caption sizes visually; stacking order should imply a sane single-column narrative.
### Conversion focus
Each section has a job. Even when the design is artistic, the page must read as a real product or brand site:
- the hero communicates value in seconds and offers one obvious next action
- proof sections (logos, quotes, metrics) feel earned, not stuffed
- pricing or CTA sections feel decisive, not buried
- the final section closes: a single strong CTA + supporting trust cue
Avoid pure mood reels with no funnel logic.
### Composition variety check
Across all per-section images, internally log the chosen composition anchor and background mode. Reject the set if:
- the same composition anchor repeats more than 2 sections in a row
- the same background mode repeats more than 3 sections in a row
- every section is inline-asset (no full-bleed background ever appears) **AND** the brief does not call for minimalism / typography-only / swiss / ultra simple
For non-minimalist briefs: push for at least one full-bleed (or duotone / atmospheric) background and at least one mini minimalist section in any multi-section site.
For minimalist briefs: this rule is suspended. Restraint is the design.
---
## 19. RESPONSE BEHAVIOR
When the user asks for a frontend design:
1. infer site type and primary conversion goal
2. infer number of sections (if unclear, use the defaults from §5: landing page = 6, full website = 8)
3. **commit out loud** to the section count and announce it ("Generating N horizontal images, one per section")
4. plan ONE horizontal image PER SECTION — always separate generations, never collapse
5. choose Hero Scale for the whole site (giant / mid / mini)
5. choose a strong visual combination (theme, type, hero arch, section system, motion, narrative spine, second-read moment)
7. for each section: pick a Composition Anchor, Background Mode, and CTA Variation — vary across sections
8. choose 4 signature components used appropriately across sections
9. enforce hero minimalism + section size variety (some giant, some mini)
10. enforce strong image usage including full-bleed backgrounds where it fits
11. lock one consistent palette across all images
12. apply §18 EXTRA CREATIVITY & IMPLEMENTATION EDGE
13. keep spacing generous, even, and clean
14. remove AI slop (including marquee / fake KPI clichés unless requested)
15. run §17 CLARITY CHECK
16. **generate every per-section horizontal image, labeled "Section X of N: <name>"**, until the full set is delivered. Do not stop early. Do not summarize. Do not return only one image.
Do not ask unnecessary follow-up questions if a strong interpretation is possible.
---
## 20. EXAMPLE INTERPRETATIONS
### Example 1
User: "make a hero section for an AI startup"
Interpretation:
- 1 horizontal image
- Hero Scale: Mid Editorial or Giant Statement
- Composition Anchor: bottom-left text over full-bleed product/atmosphere image
- Background Mode: full-bleed image with dark tonal overlay
- CTA Variation: outlined inline + small label hint
- Palette: Deep Dark or Bold Studio Solid, one consistent accent
- no cliche dashboard spam, no purple AI glow
### Example 2
User: "design 8 sections for a fintech website"
Interpretation:
- 8 separate horizontal images (one per section)
- Hero Scale: Mid Editorial (trust-driven)
- vary Composition Anchor across sections (centered low, right-third caption, bottom-left over chart visual, stacked center for closing CTA)
- Background Mode mix: solid surface, full-bleed image background once, editorial side-image at use cases
- one consistent palette (e.g. ink + paper + single brand accent)
- conversion path: hook -> proof bar -> features -> use case -> testimonial -> pricing -> FAQ -> final CTA
### Example 3
User: "creative agency landing page, 12 sections"
Interpretation:
- 12 horizontal images (one per section)
- Hero Scale: Giant Statement OR Mini Minimalist (decisive choice, not in-between)
- editorial / poster-like direction; off-grid composition appears 2-3 times
- multiple Background Modes (full-bleed image at hero + showcase, editorial side-image at case studies, solid + accent for process)
- palette consistent throughout, with one bold accent recurring
- closing CTA section: mini minimalist, strong type, single primary action
---
## 21. FINAL GOAL
Generate frontend reference images that feel:
- artistic
- premium
- clear
- structured
- image-led
- breathable
- memorable
- anti-generic
- implementation-friendly
The result should look like a top-tier website concept with strong imagery, confident creativity, and generous spacing - not a dense, repetitive AI layout.
plugins/codex/plugins/taste-skill/skills/minimalist-skill/SKILL.md
-86
View File
@@ -1,86 +0,0 @@
---
name: minimalist-ui
description: "用于生成克制、编辑感、类 Notion/Linear 的极简产品界面。"
---
# Protocol: Premium Utilitarian Minimalism UI Architect
## 1. Protocol Overview
Name: Premium Utilitarian Minimalism & Editorial UI
Description: An advanced frontend engineering directive for generating highly refined, ultra-minimalist, "document-style" web interfaces analogous to top-tier workspace platforms. This protocol strictly enforces a high-contrast warm monochrome palette, bespoke typographic hierarchies, meticulous structural macro-whitespace, bento-grid layouts, and an ultra-flat component architecture with deliberate muted pastel accents. It actively rejects standard generic SaaS design trends.
## 2. Absolute Negative Constraints (Banned Elements)
The AI must strictly avoid the following generic web development defaults:
- DO NOT use the "Inter", "Roboto", or "Open Sans" typefaces.
- DO NOT use generic, thin-line icon libraries like "Lucide", "Feather", or standard "Heroicons".
- DO NOT use Tailwind's default heavy drop shadows (e.g., `shadow-md`, `shadow-lg`, `shadow-xl`). Shadows must be practically non-existent or heavily customized to be ultra-diffuse and low opacity (< 0.05).
- DO NOT use primary colored backgrounds for large elements or sections (e.g., no bright blue, green, or red hero sections).
- DO NOT use gradients, neon colors, or 3D glassmorphism (beyond subtle navbar blurs).
- DO NOT use `rounded-full` (pill shapes) for large containers, cards, or primary buttons.
- DO NOT use emojis anywhere in code, markup, text content, headings, or alt text. Replace with proper icons or clean SVG primitives.
- DO NOT use generic placeholder names like "John Doe", "Acme Corp", or "Lorem Ipsum". Use realistic, contextual content.
- DO NOT use AI copywriting clichés: "Elevate", "Seamless", "Unleash", "Next-Gen", "Game-changer", "Delve". Write plain, specific language.
## 3. Typographic Architecture
The interface must rely on extreme typographic contrast and premium font selection to establish an editorial feel.
- Primary Sans-Serif (Body, UI, Buttons): Use clean, geometric, or system-native fonts with character. Target: `font-family: 'SF Pro Display', 'Geist Sans', 'Helvetica Neue', 'Switzer', sans-serif`.
- Editorial Serif (Hero Headings & Quotes): Target: `font-family: 'Lyon Text', 'Newsreader', 'Playfair Display', 'Instrument Serif', serif`. Apply tight tracking (`letter-spacing: -0.02em` to `-0.04em`) and tight line-height (`1.1`).
- Monospace (Code, Keystrokes, Meta-data): Target: `font-family: 'Geist Mono', 'SF Mono', 'JetBrains Mono', monospace`.
- Text Colors: Body text must never be absolute black (`#000000`). Use off-black/charcoal (`#111111` or `#2F3437`) with a generous `line-height` of `1.6` for legibility. Secondary text should be muted gray (`#787774`).
## 4. Color Palette (Warm Monochrome + Spot Pastels)
Color is a scarce resource, utilized only for semantic meaning or subtle accents.
- Canvas / Background: Pure White `#FFFFFF` or Warm Bone/Off-White `#F7F6F3` / `#FBFBFA`.
- Primary Surface (Cards): `#FFFFFF` or `#F9F9F8`.
- Structural Borders / Dividers: Ultra-light gray `#EAEAEA` or `rgba(0,0,0,0.06)`.
- Accent Colors: Exclusively use highly desaturated, washed-out pastels for tags, inline code backgrounds, or subtle icon backgrounds.
- Pale Red: `#FDEBEC` (Text: `#9F2F2D`)
- Pale Blue: `#E1F3FE` (Text: `#1F6C9F`)
- Pale Green: `#EDF3EC` (Text: `#346538`)
- Pale Yellow: `#FBF3DB` (Text: `#956400`)
## 5. Component Specifications
- Bento Box Feature Grids:
- Utilize asymmetrical CSS Grid layouts.
- Cards must have exactly `border: 1px solid #EAEAEA`.
- Border-radius must be crisp: `8px` or `12px` maximum.
- Internal padding must be generous (e.g., `24px` to `40px`).
- Primary Call-To-Action (Buttons):
- Solid background `#111111`, text `#FFFFFF`.
- Slight border-radius (`4px` to `6px`). No box-shadow.
- Hover state should be a subtle color shift to `#333333` or a micro-scale `transform: scale(0.98)`.
- Tags & Status Badges:
- Pill-shaped (`border-radius: 9999px`), very small typography (`text-xs`), uppercase with wide tracking (`letter-spacing: 0.05em`).
- Background must use the defined Muted Pastels.
- Accordions (FAQ):
- Strip all container boxes. Separate items only with a `border-bottom: 1px solid #EAEAEA`.
- Use a clean, sharp `+` and `-` icon for the toggle state.
- Keystroke Micro-UIs:
- Render shortcuts as physical keys using `<kbd>` tags: `border: 1px solid #EAEAEA`, `border-radius: 4px`, `background: #F7F6F3`, using the Monospace font.
- Faux-OS Window Chrome:
- When mocking up software, wrap it in a minimalist container with a white top bar containing three small, light gray circles (replicating macOS window controls).
## 6. Iconography & Imagery Directives
- System Icons: Use "Phosphor Icons (Bold or Fill weights)" or "Radix UI Icons" for a technical, slightly thicker-stroke aesthetic. Standardize stroke width across all icons.
- Illustrations: Monochromatic, rough continuous-line ink sketches on a white background, featuring a single offset geometric shape filled with a muted pastel color.
- Photography: Use high-quality, desaturated images with a warm tone. Apply subtle overlays (`opacity: 0.04` warm grain) to blend photos into the monochrome palette. Never use oversaturated stock photos. Use reliable placeholders like `https://picsum.photos/seed/{context}/1200/800` when real assets are unavailable.
- Hero & Section Backgrounds: Sections should not feel empty and flat. Use subtle full-width background imagery at very low opacity, soft radial light spots (`radial-gradient` with warm tones at `opacity: 0.03`), or minimal geometric line patterns to add depth without breaking the clean aesthetic.
## 7. Subtle Motion & Micro-Animations
Motion should feel invisible — present but never distracting. The goal is quiet sophistication, not spectacle.
- Scroll Entry: Elements fade in gently as they enter the viewport. Use `translateY(12px)` + `opacity: 0` resolving over `600ms` with `cubic-bezier(0.16, 1, 0.3, 1)`. Use `IntersectionObserver`, never `window.addEventListener('scroll')`.
- Hover States: Cards lift with an ultra-subtle shadow shift (`box-shadow` transitioning from `0 0 0` to `0 2px 8px rgba(0,0,0,0.04)` over `200ms`). Buttons respond with `scale(0.98)` on `:active`.
- Staggered Reveals: Lists and grid items enter with a cascade delay (`animation-delay: calc(var(--index) * 80ms)`). Never mount everything at once.
- Background Ambient Motion: Optional. A single, very slow-moving radial gradient blob (`animation-duration: 20s+`, `opacity: 0.02-0.04`) drifting behind hero sections. Must be applied to a `position: fixed; pointer-events: none` layer. Never on scrolling containers.
- Performance: Animate exclusively via `transform` and `opacity`. No layout-triggering properties (`top`, `left`, `width`, `height`). Use `will-change: transform` sparingly and only on actively animating elements.
- Reduced Motion (mandatory): Gate scroll-entry, staggered reveals, and ambient background motion behind `@media (prefers-reduced-motion: no-preference)`, and add a `@media (prefers-reduced-motion: reduce)` block that disables them so content appears instantly at rest. Hover and `:active` feedback may remain.
## 8. Execution Protocol
When tasked with writing frontend code (HTML, React, Tailwind, Vue) or designing a layout:
1. Establish the macro-whitespace first. Use massive vertical padding between sections (e.g., `py-24` or `py-32` in Tailwind).
2. Constrain the main typography content width to `max-w-4xl` or `max-w-5xl`.
3. Apply the custom typographic hierarchy and monochromatic color variables immediately.
4. Ensure every card, divider, and border adheres strictly to the `1px solid #EAEAEA` rule.
5. Add scroll-entry animations to all major content blocks.
6. Ensure sections have visual depth through imagery, ambient gradients, or subtle textures — no empty flat backgrounds.
7. Provide code that reflects this high-end, uncluttered, editorial aesthetic natively without requiring manual adjustments.
plugins/codex/plugins/taste-skill/skills/output-skill/SKILL.md
-49
View File
@@ -1,49 +0,0 @@
---
name: full-output-enforcement
description: "用于约束 AI 完整输出代码，避免占位注释、省略实现和半成品交付。"
---
# Full-Output Enforcement
## Baseline
Treat every task as production-critical. A partial output is a broken output. Do not optimize for brevity — optimize for completeness. If the user asks for a full file, deliver the full file. If the user asks for 5 components, deliver 5 components. No exceptions.
## Banned Output Patterns
The following patterns are hard failures. Never produce them:
**In code blocks:** `// ...`, `// rest of code`, `// implement here`, `// TODO`, `/* ... */`, `// similar to above`, `// continue pattern`, `// add more as needed`, bare `...` standing in for omitted code
**In prose:** "Let me know if you want me to continue", "I can provide more details if needed", "for brevity", "the rest follows the same pattern", "similarly for the remaining", "and so on" (when replacing actual content), "I'll leave that as an exercise"
**Structural shortcuts:** Outputting a skeleton when the request was for a full implementation. Showing the first and last section while skipping the middle. Replacing repeated logic with one example and a description. Describing what code should do instead of writing it.
## Execution Process
1. **Scope** — Read the full request. Count how many distinct deliverables are expected (files, functions, sections, answers). Lock that number.
2. **Build** — Generate every deliverable completely. No partial drafts, no "you can extend this later."
3. **Cross-check** — Before output, re-read the original request. Compare your deliverable count against the scope count. If anything is missing, add it before responding.
## Handling Long Outputs
When a response approaches the token limit:
- Do not compress remaining sections to squeeze them in.
- Do not skip ahead to a conclusion.
- Write at full quality up to a clean breakpoint (end of a function, end of a file, end of a section).
- End with:
```
[PAUSED — X of Y complete. Send "continue" to resume from: next section name]
```
On "continue", pick up exactly where you stopped. No recap, no repetition.
## Quick Check
Before finalizing any response, verify:
- No banned patterns from the list above appear anywhere in the output
- Every item the user requested is present and finished
- Code blocks contain actual runnable code, not descriptions of what code would do
- Nothing was shortened to save space
plugins/codex/plugins/taste-skill/skills/redesign-skill/SKILL.md
-181
View File
@@ -1,181 +0,0 @@
---
name: redesign-existing-projects
description: "用于审计并升级已有项目界面，修复布局、层级、间距和通用 AI 风格问题。"
---
# Redesign Skill
## How This Works
When applied to an existing project, follow this sequence:
1. **Scan** — Read the codebase. Identify the framework, styling method (Tailwind, vanilla CSS, styled-components, etc.), and current design patterns.
2. **Diagnose** — Run through the audit below. List every generic pattern, weak point, and missing state you find.
3. **Fix** — Apply targeted upgrades working with the existing stack. Do not rewrite from scratch. Improve what's there.
## Design Audit
### Typography
Check for these problems and fix them:
- **Browser default fonts or Inter everywhere.** Replace with a font that has character. Good options: `Geist`, `Outfit`, `Cabinet Grotesk`, `Satoshi`. For editorial/creative projects, pair a serif header with a sans-serif body.
- **Headlines lack presence.** Increase size for display text, tighten letter-spacing, reduce line-height. Headlines should feel heavy and intentional.
- **Body text too wide.** Limit paragraph width to roughly 65 characters. Increase line-height for readability.
- **Only Regular (400) and Bold (700) weights used.** Introduce Medium (500) and SemiBold (600) for more subtle hierarchy.
- **Numbers in proportional font.** Use a monospace font or enable tabular figures (`font-variant-numeric: tabular-nums`) for data-heavy interfaces.
- **Missing letter-spacing adjustments.** Use negative tracking for large headers, positive tracking for small caps or labels.
- **All-caps subheaders everywhere.** Try lowercase italics, sentence case, or small-caps instead.
- **Orphaned words.** Single words sitting alone on the last line. Fix with `text-wrap: balance` or `text-wrap: pretty`.
### Color and Surfaces
- **Pure `#000000` background.** Replace with off-black, dark charcoal, or tinted dark (`#0a0a0a`, `#121212`, or a dark navy).
- **Oversaturated accent colors.** Keep saturation below 80%. Desaturate accents so they blend with neutrals instead of screaming.
- **More than one accent color.** Pick one. Remove the rest. Consistency beats variety.
- **Mixing warm and cool grays.** Stick to one gray family. Tint all grays with a consistent hue (warm or cool, not both).
- **Purple/blue "AI gradient" aesthetic.** This is the most common AI design fingerprint. Replace with neutral bases and a single, considered accent.
- **Generic `box-shadow`.** Tint shadows to match the background hue. Use colored shadows (e.g., dark blue shadow on a blue background) instead of pure black at low opacity.
- **Flat design with zero texture.** Add subtle noise, grain, or micro-patterns to backgrounds. Pure flat vectors feel sterile.
- **Perfectly even gradients.** Break the uniformity with radial gradients, noise overlays, or mesh gradients instead of standard linear 45-degree fades.
- **Inconsistent lighting direction.** Audit all shadows to ensure they suggest a single, consistent light source.
- **Random dark sections in a light mode page (or vice versa).** A single dark-background section breaking an otherwise light page looks like a copy-paste accident. Either commit to a full dark mode or keep a consistent background tone throughout. If contrast is needed, use a slightly darker shade of the same palette — not a sudden jump to `#111` in the middle of a cream page.
- **Empty, flat sections with no visual depth.** Sections that are just text on a plain background feel unfinished. Add high-quality background imagery (blurred, overlaid, or masked), subtle patterns, or ambient gradients. Use reliable placeholder sources like `https://picsum.photos/seed/{name}/1920/1080` when real assets are not available. Experiment with background images behind hero sections, feature blocks, or CTAs — even a subtle full-width photo at low opacity adds presence.
### Layout
- **Everything centered and symmetrical.** Break symmetry with offset margins, mixed aspect ratios, or left-aligned headers over centered content.
- **Three equal card columns as feature row.** This is the most generic AI layout. Replace with a 2-column zig-zag, asymmetric grid, horizontal scroll, or masonry layout.
- **Using `height: 100vh` for full-screen sections.** Replace with `min-height: 100dvh` to prevent layout jumping on mobile browsers (iOS Safari viewport bug).
- **Complex flexbox percentage math.** Replace with CSS Grid for reliable multi-column structures.
- **No max-width container.** Add a container constraint (around 1200-1440px) with auto margins so content doesn't stretch edge-to-edge on wide screens.
- **Cards of equal height forced by flexbox.** Allow variable heights or use masonry when content varies in length.
- **Uniform border-radius on everything.** Vary the radius: tighter on inner elements, softer on containers.
- **No overlap or depth.** Elements sit flat next to each other. Use negative margins to create layering and visual depth.
- **Symmetrical vertical padding.** Top and bottom padding are always identical. Adjust optically — bottom padding often needs to be slightly larger.
- **Dashboard always has a left sidebar.** Consider top navigation, a floating command menu, or a collapsible panel when it fits the project's navigation.
- **Desktop sidebar collapses to nothing.** For collapsible sidebars, keep expanded labels as the default and offer an opt-in icon rail around 56-72px wide, with one icon per destination. Keep the active item highlighted and replace group headings with thin dividers. Below the project's tablet breakpoint, use an off-canvas drawer instead of a rail.
- **Missing whitespace.** Double the spacing. Let the design breathe. Dense layouts work for data dashboards, not for marketing pages.
- **Buttons not bottom-aligned in card groups.** When cards have different content lengths, CTAs end up at random heights. Pin buttons to the bottom of each card so they form a clean horizontal line regardless of content above.
- **Feature lists starting at different vertical positions.** In pricing tables or comparison cards, the list of features should start at the same Y position across all columns. Use consistent spacing above the list or fixed-height title/price blocks.
- **Inconsistent vertical rhythm in side-by-side elements.** When placing cards, columns, or panels next to each other, align shared elements (titles, descriptions, prices, buttons) across all items. Misaligned baselines make the layout look broken.
- **Mathematical alignment that looks optically wrong.** Centering by the math doesn't always look centered to the eye. Icons next to text, play buttons in circles, or text in buttons often need 1-2px optical adjustments to feel right.
### Interactivity and States
- **No hover states on buttons.** Add background shift, slight scale, or translate on hover.
- **No active/pressed feedback.** Add a subtle `scale(0.98)` or `translateY(1px)` on press to simulate a physical click.
- **Instant transitions with zero duration.** Add smooth transitions (200-300ms) to all interactive elements.
- **Missing focus ring.** Ensure visible focus indicators for keyboard navigation. This is an accessibility requirement, not optional.
- **No loading states.** Replace generic circular spinners with skeleton loaders that match the layout shape.
- **No empty states.** An empty dashboard showing nothing is a missed opportunity. Design a composed "getting started" view.
- **No error states.** Add clear, inline error messages for forms. Do not use `window.alert()`.
- **Dead links.** Buttons that link to `#`. Either link to real destinations or visually disable them.
- **No indication of current page in navigation.** Style the active nav link differently so users know where they are.
- **Icon-only navigation without names or usable targets.** Keep label text in the DOM, visually hidden in the rail, and show tooltips on hover and keyboard focus. Give rail items and the collapse/expand control targets of at least 44×44px. Use a button with an accessible name and `aria-expanded` for the control.
- **Scroll jumping.** Anchor clicks jump instantly. Add `scroll-behavior: smooth`.
- **Animations using `top`, `left`, `width`, `height`.** Switch to `transform` and `opacity` for GPU-accelerated, smooth animation.
### Content
- **Generic names like "John Doe" or "Jane Smith".** Use diverse, realistic-sounding names.
- **Fake round numbers like `99.99%`, `50%`, `$100.00`.** Use organic, messy data: `47.2%`, `$99.00`, `+1 (312) 847-1928`.
- **Placeholder company names like "Acme Corp", "Nexus", "SmartFlow".** Invent contextual, believable brand names.
- **AI copywriting cliches.** Never use "Elevate", "Seamless", "Unleash", "Next-Gen", "Game-changer", "Delve", "Tapestry", or "In the world of...". Write plain, specific language.
- **Exclamation marks in success messages.** Remove them. Be confident, not loud.
- **"Oops!" error messages.** Be direct: "Connection failed. Please try again."
- **Passive voice.** Use active voice: "We couldn't save your changes" instead of "Mistakes were made."
- **All blog post dates identical.** Randomize dates to appear real.
- **Same avatar image for multiple users.** Use unique assets for every distinct person.
- **Lorem Ipsum.** Never use placeholder latin text. Write real draft copy.
- **Title Case On Every Header.** Use sentence case instead.
### Component Patterns
- **Generic card look (border + shadow + white background).** Remove the border, or use only background color, or use only spacing. Cards should exist only when elevation communicates hierarchy.
- **Always one filled button + one ghost button.** Add text links or tertiary styles to reduce visual noise.
- **Pill-shaped "New" and "Beta" badges.** Try square badges, flags, or plain text labels.
- **Accordion FAQ sections.** Use a side-by-side list, searchable help, or inline progressive disclosure.
- **3-card carousel testimonials with dots.** Replace with a masonry wall, embedded social posts, or a single rotating quote.
- **Pricing table with 3 towers.** Highlight the recommended tier with color and emphasis, not just extra height.
- **Modals for everything.** Use inline editing, slide-over panels, or expandable sections instead of popups for simple actions.
- **Avatar circles exclusively.** Try squircles or rounded squares for a less generic look.
- **Light/dark toggle always a sun/moon switch.** Use a dropdown, system preference detection, or integrate it into settings.
- **Footer link farm with 4 columns.** Simplify. Focus on main navigational paths and legally required links.
### Iconography
- **Lucide or Feather icons exclusively.** These are the "default" AI icon choice. Use Phosphor, Heroicons, or a custom set for differentiation.
- **Rocketship for "Launch", shield for "Security".** Replace cliche metaphors with less obvious icons (bolt, fingerprint, spark, vault).
- **Inconsistent stroke widths across icons.** Audit all icons and standardize to one stroke weight.
- **Missing favicon.** Always include a branded favicon.
- **Stock "diverse team" photos.** Use real team photos, candid shots, or a consistent illustration style instead of uncanny stock imagery.
### Code Quality
- **Div soup.** Use semantic HTML: `<nav>`, `<main>`, `<article>`, `<aside>`, `<section>`.
- **Collapsed navigation is inert or hidden.** Keep the rail and collapse/expand control outside hidden or `inert` ancestors, exposed to assistive technology and operable by pointer and keyboard, with visible focus indicators. Suppress focus and interaction in inactive expanded sidebar content with `inert`, `hidden`, or `display: none`; use explicit tab-stop and interaction management if a visual transition keeps it rendered. `aria-hidden="true"` alone does not remove descendants from the tab order.
- **Inline styles mixed with CSS classes.** Move all styling to the project's styling system.
- **Hardcoded pixel widths.** Use relative units (`%`, `rem`, `em`, `max-width`) for flexible layouts.
- **Missing alt text on images.** Describe image content for screen readers. Never leave `alt=""` or `alt="image"` on meaningful images.
- **Arbitrary z-index values like `9999`.** Establish a clean z-index scale in the theme/variables.
- **Commented-out dead code.** Remove all debug artifacts before shipping.
- **Import hallucinations.** Check that every import actually exists in `package.json` or the project dependencies.
- **Missing meta tags.** Add proper `<title>`, `description`, `og:image`, and social sharing meta tags.
### Strategic Omissions (What AI Typically Forgets)
- **No legal links.** Add privacy policy and terms of service links in the footer.
- **No "back" navigation.** Dead ends in user flows. Every page needs a way back.
- **No custom 404 page.** Design a helpful, branded "page not found" experience.
- **No form validation.** Add client-side validation for emails, required fields, and format checks.
- **No "skip to content" link.** Essential for keyboard users. Add a hidden skip-link.
- **No cookie consent.** If required by jurisdiction, add a compliant consent banner.
## Upgrade Techniques
When upgrading a project, pull from these high-impact techniques to replace generic patterns:
### Typography Upgrades
- **Variable font animation.** Interpolate weight or width on scroll or hover for text that feels alive.
- **Outlined-to-fill transitions.** Text starts as a stroke outline and fills with color on scroll entry or interaction.
- **Text mask reveals.** Large typography acting as a window to video or animated imagery behind it.
### Layout Upgrades
- **Broken grid / asymmetry.** Elements that deliberately ignore column structure — overlapping, bleeding off-screen, or offset with calculated randomness.
- **Whitespace maximization.** Aggressive use of negative space to force focus on a single element.
- **Parallax card stacks.** Sections that stick and physically stack over each other during scroll.
- **Split-screen scroll.** Two halves of the screen sliding in opposite directions.
### Motion Upgrades
- **Smooth scroll with inertia.** Decouple scrolling from browser defaults for a heavier, cinematic feel.
- **Staggered entry.** Elements cascade in with slight delays, combining Y-axis translation with opacity fade. Never mount everything at once.
- **Spring physics.** Replace linear easing with spring-based motion for a natural, weighty feel on all interactive elements.
- **Scroll-driven reveals.** Content entering through expanding masks, wipes, or draw-on SVG paths tied to scroll progress.
### Surface Upgrades
- **True glassmorphism.** Go beyond `backdrop-filter: blur`. Add a 1px inner border and a subtle inner shadow to simulate edge refraction.
- **Spotlight borders.** Card borders that illuminate dynamically under the cursor.
- **Grain and noise overlays.** A fixed, pointer-events-none overlay with subtle noise to break digital flatness.
- **Colored, tinted shadows.** Shadows that carry the hue of the background rather than using generic black.
## Fix Priority
Apply changes in this order for maximum visual impact with minimum risk:
1. **Font swap** — biggest instant improvement, lowest risk
2. **Color palette cleanup** — remove clashing or oversaturated colors
3. **Hover and active states** — makes the interface feel alive
4. **Layout and spacing** — proper grid, max-width, consistent padding
5. **Replace generic components** — swap cliche patterns for modern alternatives
6. **Add loading, empty, and error states** — makes it feel finished
7. **Polish typography scale and spacing** — the premium final touch
## Rules
- Work with the existing tech stack. Do not migrate frameworks or styling libraries.
- Do not break existing functionality. Test after every change.
- Before importing any new library, check the project's dependency file first.
- If the project uses Tailwind, check the version (v3 vs v4) before modifying config.
- If the project has no framework, use vanilla CSS.
- Keep changes reviewable and focused. Small, targeted improvements over big rewrites.
plugins/codex/plugins/taste-skill/skills/soft-skill/SKILL.md
-98
View File
@@ -1,98 +0,0 @@
---
name: high-end-visual-design
description: "用于生成高端、柔和、留白充足且具有精致动效的视觉设计。"
---
# Agent Skill: Principal UI/UX Architect & Motion Choreographer (Awwwards-Tier)
## 1. Meta Information & Core Directive
- **Persona:** `Vanguard_UI_Architect`
- **Objective:** You engineer $150k+ agency-level digital experiences, not just websites. Your output must exude haptic depth, cinematic spatial rhythm, obsessive micro-interactions, and flawless fluid motion.
- **The Variance Mandate:** NEVER generate the exact same layout or aesthetic twice in a row. You must dynamically combine different premium layout archetypes and texture profiles while strictly adhering to the elite "Apple-esque / Linear-tier" design language.
## 2. THE "ABSOLUTE ZERO" DIRECTIVE (STRICT ANTI-PATTERNS)
If your generated code includes ANY of the following, the design instantly fails:
- **Banned Fonts:** Inter, Roboto, Arial, Open Sans, Helvetica. (Assume premium fonts like `Geist`, `Clash Display`, `PP Editorial New`, or `Plus Jakarta Sans` are available).
- **Banned Icons:** Standard thick-stroked Lucide, FontAwesome, or Material Icons. Use only ultra-light, precise lines (e.g., Phosphor Light, Remix Line).
- **Banned Borders & Shadows:** Generic 1px solid gray borders. Harsh, dark drop shadows (`shadow-md`, `rgba(0,0,0,0.3)`).
- **Banned Layouts:** Edge-to-edge sticky navbars glued to the top. Symmetrical, boring 3-column Bootstrap-style grids without massive whitespace gaps.
- **Banned Motion:** Standard `linear` or `ease-in-out` transitions. Instant state changes without interpolation.
## 3. THE CREATIVE VARIANCE ENGINE
Before writing code, silently "roll the dice" and select ONE combination from the following archetypes based on the prompt's context to ensure the output is uniquely tailored but always premium:
### A. Vibe & Texture Archetypes (Pick 1)
1. **Ethereal Glass (SaaS / AI / Tech):** Deepest OLED black (`#050505`), radial mesh gradients (e.g., subtle glowing purple/emerald orbs) in the background. Vantablack cards with heavy `backdrop-blur-2xl` and pure white/10 hairlines. Wide geometric Grotesk typography.
2. **Editorial Luxury (Lifestyle / Real Estate / Agency):** Warm creams (`#FDFBF7`), muted sage, or deep espresso tones. High-contrast Variable Serif fonts for massive headings. Subtle CSS noise/film-grain overlay (`opacity-[0.03]`) for a physical paper feel.
3. **Soft Structuralism (Consumer / Health / Portfolio):** Silver-grey or completely white backgrounds. Massive bold Grotesk typography. Airy, floating components with unbelievably soft, highly diffused ambient shadows.
### B. Layout Archetypes (Pick 1)
1. **The Asymmetrical Bento:** A masonry-like CSS Grid of varying card sizes (e.g., `col-span-8 row-span-2` next to stacked `col-span-4` cards) to break visual monotony.
- **Mobile Collapse:** Falls back to a single-column stack (`grid-cols-1`) with generous vertical gaps (`gap-6`). All `col-span` overrides reset to `col-span-1`.
2. **The Z-Axis Cascade:** Elements are stacked like physical cards, slightly overlapping each other with varying depths of field, some with a subtle `-2deg` or `3deg` rotation to break the digital grid.
- **Mobile Collapse:** Remove all rotations and negative-margin overlaps below `768px`. Stack vertically with standard spacing. Overlapping elements cause touch-target conflicts on mobile.
3. **The Editorial Split:** Massive typography on the left half (`w-1/2`), with interactive, scrollable horizontal image pills or staggered interactive cards on the right.
- **Mobile Collapse:** Converts to a full-width vertical stack (`w-full`). Typography block sits on top, interactive content flows below with horizontal scroll preserved if needed.
**Mobile Override (Universal):** Any asymmetric layout above `md:` MUST aggressively fall back to `w-full`, `px-4`, `py-8` on viewports below `768px`. Never use `h-screen` for full-height sections — always use `min-h-[100dvh]` to prevent iOS Safari viewport jumping.
## 4. HAPTIC MICRO-AESTHETICS (COMPONENT MASTERY)
### A. The "Double-Bezel" (Doppelrand / Nested Architecture)
Never place a premium card, image, or container flatly on the background. They must look like physical, machined hardware (like a glass plate sitting in an aluminum tray) using nested enclosures.
- **Outer Shell:** A wrapper `div` with a subtle background (`bg-black/5` or `bg-white/5`), a hairline outer border (`ring-1 ring-black/5` or `border border-white/10`), a specific padding (e.g., `p-1.5` or `p-2`), and a large outer radius (`rounded-[2rem]`).
- **Inner Core:** The actual content container inside the shell. It has its own distinct background color, its own inner highlight (`shadow-[inset_0_1px_1px_rgba(255,255,255,0.15)]`), and a mathematically calculated smaller radius (e.g., `rounded-[calc(2rem-0.375rem)]`) for concentric curves.
### B. Nested CTA & "Island" Button Architecture
- **Structure:** Primary interactive buttons must be fully rounded pills (`rounded-full`) with generous padding (`px-6 py-3`).
- **The "Button-in-Button" Trailing Icon:** If a button has an arrow (`↗`), it NEVER sits naked next to the text. It must be nested inside its own distinct circular wrapper (e.g., `w-8 h-8 rounded-full bg-black/5 dark:bg-white/10 flex items-center justify-center`) placed completely flush with the main button's right inner padding.
### C. Spatial Rhythm & Tension
- **Macro-Whitespace:** Double your standard padding. Use `py-24` to `py-40` for sections. Allow the design to breathe heavily.
- **Eyebrow Tags:** Precede major H1/H2s with a microscopic, pill-shaped badge (`rounded-full px-3 py-1 text-[10px] uppercase tracking-[0.2em] font-medium`).
## 5. MOTION CHOREOGRAPHY (FLUID DYNAMICS)
Never use default transitions. All motion must simulate real-world mass and spring physics. Use custom cubic-beziers (e.g., `transition-all duration-700 ease-[cubic-bezier(0.32,0.72,0,1)]`).
### A. The "Fluid Island" Nav & Hamburger Reveal
- **Closed State:** The Navbar is a floating glass pill detached from the top (`mt-6`, `mx-auto`, `w-max`, `rounded-full`).
- **The Hamburger Morph:** On click, the 2 or 3 lines of the hamburger icon must fluidly rotate and translate to form a perfect 'X' (`rotate-45` and `-rotate-45` with absolute positioning), not just disappear.
- **The Modal Expansion:** The menu should open as a massive, screen-filling overlay with a heavy glass effect (`backdrop-blur-3xl bg-black/80` or `bg-white/80`).
- **Staggered Mask Reveal:** The navigation links inside the expanded state do not just appear. They fade in and slide up from an invisible box (`translate-y-12 opacity-0` to `translate-y-0 opacity-100`) with a staggered delay (`delay-100`, `delay-150`, `delay-200` for each item).
### B. Magnetic Button Hover Physics
- Use the `group` utility. On hover, do not just change the background color.
- Scale the entire button down slightly (`active:scale-[0.98]`) to simulate physical pressing.
- The nested inner icon circle should translate diagonally (`group-hover:translate-x-1 group-hover:-translate-y-[1px]`) and scale up slightly (`scale-105`), creating internal kinetic tension.
### C. Scroll Interpolation (Entry Animations)
- Elements never appear statically on load. As they enter the viewport, they must execute a gentle, heavy fade-up (`translate-y-16 blur-md opacity-0` resolving to `translate-y-0 blur-0 opacity-100` over 800ms+).
- For JavaScript-driven scroll reveals, use `IntersectionObserver` or Framer Motion's `whileInView`. Never use `window.addEventListener('scroll')` — it causes continuous reflows and kills mobile performance.
## 6. PERFORMANCE GUARDRAILS
- **GPU-Safe Animation:** Never animate `top`, `left`, `width`, or `height`. Animate exclusively via `transform` and `opacity`. Use `will-change: transform` sparingly and only on elements that are actively animating.
- **Blur Constraints:** Apply `backdrop-blur` only to fixed or sticky elements (navbars, overlays). Never apply blur filters to scrolling containers or large content areas — this causes continuous GPU repaints and severe mobile frame drops.
- **Grain/Noise Overlays:** Apply noise textures exclusively to fixed, `pointer-events-none` pseudo-elements (`position: fixed; inset: 0; z-index: 50`). Never attach them to scrolling containers.
- **Z-Index Discipline:** Do not use arbitrary `z-50` or `z-[9999]`. Reserve z-indexes strictly for systemic layers: sticky nav, modals, overlays, tooltips.
## 7. EXECUTION PROTOCOL
When generating UI code, follow this exact sequence:
1. **[SILENT THOUGHT]** Roll the Variance Engine (Section 3). Choose your Vibe and Layout Archetypes based on the prompt's context to ensure a unique output.
2. **[SCAFFOLD]** Establish the background texture, macro-whitespace scale, and massive typography sizes.
3. **[ARCHITECT]** Build the DOM strictly using the "Double-Bezel" (Doppelrand) technique for all major cards, inputs, and feature grids. Use exaggerated squircle radii (`rounded-[2rem]`).
4. **[CHOREOGRAPH]** Inject the custom `cubic-bezier` transitions, the staggered navigation reveals, and the button-in-button hover physics.
5. **[OUTPUT]** Deliver flawless, pixel-perfect React/Tailwind/HTML code. Do not include basic, generic fallbacks.
## 8. PRE-OUTPUT CHECKLIST
Evaluate your code against this matrix before delivering. This is the last filter.
- [ ] No banned fonts, icons, borders, shadows, layouts, or motion patterns from Section 2 are present
- [ ] A Vibe Archetype and Layout Archetype from Section 3 were consciously selected and applied
- [ ] All major cards and containers use the Double-Bezel nested architecture (outer shell + inner core)
- [ ] CTA buttons use the Button-in-Button trailing icon pattern where applicable
- [ ] Section padding is at minimum `py-24` — the layout breathes heavily
- [ ] All transitions use custom cubic-bezier curves — no `linear` or `ease-in-out`
- [ ] Scroll entry animations are present — no element appears statically
- [ ] Layout collapses gracefully below `768px` to single-column with `w-full` and `px-4`
- [ ] All animations use only `transform` and `opacity` — no layout-triggering properties
- [ ] `backdrop-blur` is only applied to fixed/sticky elements, never to scrolling content
- [ ] The overall impression reads as "$150k agency build", not "template with nice fonts"
plugins/codex/plugins/taste-skill/skills/stitch-skill/DESIGN.md
-121
View File
@@ -1,121 +0,0 @@
# Design System: Taste Standard
**Skill:** stitch-design-taste
---
## Configuration — Set Your Style
Adjust these dials before using this design system. They control how creative, dense, and animated the output should be. Pick the level that fits your project.
| Dial | Level | Description |
|------|-------|-------------|
| **Creativity** | `8` | `1` = Ultra-minimal, Swiss, silent, monochrome. `5` = Balanced, clean but with personality. `10` = Expressive, editorial, bold typography experiments, inline images in headlines, strong asymmetry. Default: `8` |
| **Density** | `4` | `1` = Gallery-airy, massive whitespace. `5` = Balanced sections. `10` = Cockpit-dense, data-heavy. Default: `4` |
| **Variance** | `8` | `1` = Predictable, symmetric grids. `5` = Subtle offsets. `10` = Artsy chaotic, no two sections alike. Default: `8` |
| **Motion Intent** | `6` | `1` = Static, no animation noted. `5` = Subtle hover/entrance cues. `10` = Cinematic orchestration noted in every component. Default: `6` |
> **How to use:** Change the numbers above to match your project's vibe. At **Creativity 1–3**, the system produces clean, quiet, Notion-like interfaces. At **Creativity 7–10**, expect inline image typography, dramatic scale contrast, and strong editorial layouts. The rest of the rules below adapt to your chosen levels.
---
## 1. Visual Theme & Atmosphere
A restrained, gallery-airy interface with confident asymmetric layouts and fluid spring-physics motion. The atmosphere is clinical yet warm — like a well-lit architecture studio where every element earns its place through function. Density is balanced (Level 4), variance runs high (Level 8) to prevent symmetrical boredom, and motion is fluid but never theatrical (Level 6). The overall impression: expensive, intentional, alive.
## 2. Color Palette & Roles
- **Canvas White** (#F9FAFB) — Primary background surface. Warm-neutral, never clinical blue-white
- **Pure Surface** (#FFFFFF) — Card and container fill. Used with whisper shadow for elevation
- **Charcoal Ink** (#18181B) — Primary text. Zinc-950 depth — never pure black
- **Steel Secondary** (#71717A) — Body text, descriptions, metadata. Zinc-500 warmth
- **Muted Slate** (#94A3B8) — Tertiary text, timestamps, disabled states
- **Whisper Border** (rgba(226,232,240,0.5)) — Card borders, structural 1px lines. Semi-transparent for depth
- **Diffused Shadow** (rgba(0,0,0,0.05)) — Card elevation. Wide-spreading, 40px blur, -15px offset. Never harsh
### Accent Selection (Pick ONE per project)
- **Emerald Signal** (#10B981) — For growth, success, positive data dashboards
- **Electric Blue** (#3B82F6) — For productivity, SaaS, developer tools
- **Deep Rose** (#E11D48) — For creative, editorial, fashion-adjacent projects
- **Amber Warmth** (#F59E0B) — For community, social, warm-toned products
### Banned Colors
- Purple/Violet neon gradients — the "AI Purple" aesthetic
- Pure Black (#000000) — always Off-Black or Zinc-950
- Oversaturated accents above 80% saturation
- Mixed warm/cool gray systems within one project
## 3. Typography Rules
- **Display:** `Geist`, `Satoshi`, `Cabinet Grotesk`, or `Outfit` — Track-tight (`-0.025em`), controlled fluid scale, weight-driven hierarchy (700–900). Not screaming. Leading compressed (`1.1`). Alternatives forced — `Inter` is BANNED for premium contexts
- **Body:** Same family at weight 400 — Relaxed leading (`1.65`), 65ch max-width, Steel Secondary color (#71717A)
- **Mono:** `Geist Mono` or `JetBrains Mono` — For code blocks, metadata, timestamps. When density exceeds Level 7, all numbers switch to monospace
- **Scale:** Display at `clamp(2.25rem, 5vw, 3.75rem)`. Body at `1rem/1.125rem`. Mono metadata at `0.8125rem`
### Banned Fonts
- `Inter` — banned everywhere in premium/creative contexts
- Generic serif fonts (`Times New Roman`, `Georgia`, `Garamond`, `Palatino`) — BANNED. If serif is needed for editorial/creative, use only distinctive modern serifs like `Fraunces`, `Gambarino`, `Editorial New`, or `Instrument Serif`. Never use default browser serif stacks. Serif is always BANNED in dashboards or software UIs regardless
## 4. Component Stylings
* **Buttons:** Flat surface, no outer glow. Primary: accent fill with white text. Secondary: ghost/outline. Active state: `-1px translateY` or `scale(0.98)` for tactile push. Hover: subtle background shift, never glow
* **Cards/Containers:** Generously rounded corners (`2.5rem`). Pure white fill. Whisper border (`1px`, semi-transparent). Diffused shadow (`0 20px 40px -15px rgba(0,0,0,0.05)`). Internal padding `2rem–2.5rem`. Used ONLY when elevation communicates hierarchy — high-density layouts replace cards with `border-top` dividers or negative space
* **Inputs/Forms:** Label positioned above input. Helper text optional. Error text below in Deep Rose. Focus ring in accent color, `2px` offset. No floating labels. Standard `0.5rem` gap between label-input-error stack
* **Navigation:** Sleek, sticky. Icons scale on hover (Dock Magnification optional). No hamburger on desktop. Clean horizontal with generous spacing
* **Loaders:** Skeletal shimmer matching exact layout dimensions and rounded corners. Shifting light reflection across placeholder shapes. Never circular spinners
* **Empty States:** Composed illustration or icon composition with guidance text. Never just "No data found"
* **Error States:** Inline, contextual. Red accent underline or border. Clear recovery action
## 5. Hero Section
The Hero is the first impression — it must be striking, creative, and never generic.
- **Inline Image Typography:** Embed small, contextual photos or visuals directly between words or letters in the headline. Example: "We build [photo of hands typing] digital [photo of screen] products" — images sit inline at type-height, rounded, acting as visual punctuation between words. This is the signature creative technique
- **No Overlapping Elements:** Text must never overlap images or other text. Every element has its own clear spatial zone. No z-index stacking of content layers, no absolute-positioned headlines over images. Clean separation always
- **No Filler Text:** "Scroll to explore", "Swipe down", scroll arrow icons, bouncing chevrons, and any instructional UI chrome are BANNED. The user knows how to scroll. Let the content pull them in naturally
- **Asymmetric Structure:** Centered Hero layouts are BANNED at this variance level. Use Split Screen (50/50), Left-Aligned text / Right visual, or Asymmetric Whitespace with large empty zones
- **CTA Restraint:** Maximum one primary CTA button. No secondary "Learn more" links. No redundant micro-copy below the headline
## 6. Layout Principles
- **Grid-First:** CSS Grid for all structural layouts. Never flexbox percentage math (`calc(33% - 1rem)` is BANNED)
- **No Overlapping:** Elements must never overlap each other. No absolute-positioned layers stacking content on content. Every element occupies its own grid cell or flow position. Clean, separated spatial zones
- **Feature Sections:** The "3 equal cards in a row" pattern is BANNED. Use 2-column Zig-Zag, asymmetric Bento grids (2fr 1fr 1fr), or horizontal scroll galleries
- **Containment:** All content within `max-width: 1400px`, centered. Generous horizontal padding (`1rem` mobile, `2rem` tablet, `4rem` desktop)
- **Full-Height:** Use `min-height: 100dvh` — never `height: 100vh` (iOS Safari address bar jump)
- **Bento Architecture:** For feature grids, use Row 1: 3 columns | Row 2: 2 columns (70/30 split). Each tile contains a perpetual micro-animation
## 7. Responsive Rules
Every screen must work flawlessly across all viewports. **Responsive is not optional — it is a hard requirement. Every single element must be tested at 375px, 768px, and 1440px.**
- **Mobile-First Collapse (< 768px):** All multi-column layouts collapse to a strict single column. `width: 100%`, `padding: 1rem`, `gap: 1.5rem`. No exceptions
- **No Horizontal Scroll:** Horizontal overflow on mobile is a critical failure. All elements must fit within viewport width. If any element causes horizontal scroll, the design is broken
- **Typography Scaling:** Headlines scale down gracefully via `clamp()`. Body text stays `1rem` minimum. Never shrink body below `14px`. Headlines must remain readable on 375px screens
- **Touch Targets:** All interactive elements minimum `44px` tap target. Generous spacing between clickable items. Buttons must be full-width on mobile
- **Image Behavior:** Hero and inline images scale proportionally. Inline typography images (photos between words) stack below the headline on mobile instead of inline
- **Navigation:** Desktop horizontal nav collapses to a clean mobile menu (slide-in or full-screen overlay). No tiny hamburger icons without labels
- **Cards & Grids:** Bento grids and asymmetric layouts revert to stacked single-column cards with full-width. Maintain internal padding (`1rem`)
- **Spacing Consistency:** Vertical section gaps reduce proportionally on mobile (`clamp(3rem, 8vw, 6rem)`). Never cramped, never excessively airy
- **Testing Viewports:** Designs must be verified at: `375px` (iPhone SE), `390px` (iPhone 14), `768px` (iPad), `1024px` (small laptop), `1440px` (desktop)
## 8. Motion & Interaction (Code-Phase Intent)
> **Note:** Stitch generates static screens — it does not animate. This section documents the **intended motion behavior** so that the coding agent (Antigravity, Cursor, etc.) knows exactly how to implement animations when building the exported design into a live product.
- **Physics Engine:** Spring-based exclusively. `stiffness: 100, damping: 20`. No linear easing anywhere. Premium, weighty feel on all interactive elements
- **Perpetual Micro-Loops:** Every active dashboard component has an infinite-loop state — Pulse on status dots, Typewriter on search bars, Float on feature icons, Shimmer on loading states
- **Staggered Orchestration:** Lists and grids mount with cascaded delays (`animation-delay: calc(var(--index) * 100ms)`). Waterfall reveals, never instant mount
- **Layout Transitions:** Smooth re-ordering via shared element IDs. Items swap positions with physics, simulating real-time intelligence
- **Hardware Rules:** Animate ONLY `transform` and `opacity`. Never `top`, `left`, `width`, `height`. Grain/noise filters on fixed, pointer-events-none pseudo-elements only
- **Performance:** CPU-heavy perpetual animations isolated in microscopic leaf components. Never trigger parent re-renders. Target 60fps minimum
## 9. Anti-Patterns (Banned)
- No emojis — anywhere in UI, code, or alt text
- No `Inter` font — use `Geist`, `Outfit`, `Cabinet Grotesk`, `Satoshi`
- No generic serif fonts (`Times New Roman`, `Georgia`, `Garamond`) — if serif is needed, use distinctive modern serifs only (`Fraunces`, `Instrument Serif`)
- No pure black (`#000000`) — Off-Black or Zinc-950 only
- No neon outer glows or default box-shadow glows
- No oversaturated accent colors above 80%
- No excessive gradient text on large headers
- No custom mouse cursors
- No overlapping elements — text never overlaps images or other content. Clean spatial separation always
- No 3-column equal card layouts for features
- No centered Hero sections (at this variance level)
- No filler UI text: "Scroll to explore", "Swipe down", "Discover more below", scroll arrows, bouncing chevrons — all BANNED
- No generic names: "John Doe", "Sarah Chan", "Acme", "Nexus", "SmartFlow"
- No fake round numbers: `99.99%`, `50%`, `1234567` — use organic data: `47.2%`, `+1 (312) 847-1928`
- No AI copywriting clichés: "Elevate", "Seamless", "Unleash", "Next-Gen", "Revolutionize"
- No broken Unsplash links — use `picsum.photos/seed/{id}/800/600` or SVG UI Avatars
- No generic `shadcn/ui` defaults — customize radii, colors, shadows to match this system
- No `z-index` spam — use only for Navbar, Modal, Overlay layer contexts
- No `h-screen` — always `min-h-[100dvh]`
- No circular loading spinners — skeletal shimmer only
plugins/codex/plugins/taste-skill/skills/stitch-skill/SKILL.md
-184
View File
@@ -1,184 +0,0 @@
---
name: stitch-design-taste
description: "用于生成 Google Stitch 兼容的 DESIGN.md 语义设计系统规则。"
---
# Stitch Design Taste — Semantic Design System Skill
## Overview
This skill generates `DESIGN.md` files optimized for Google Stitch screen generation. It translates the battle-tested anti-slop frontend engineering directives into Stitch's native semantic design language — descriptive, natural-language rules paired with precise values that Stitch's AI agent can interpret to produce premium, non-generic interfaces.
The generated `DESIGN.md` serves as the **single source of truth** for prompting Stitch to generate new screens that align with a curated, high-agency design language. Stitch interprets design through **"Visual Descriptions"** supported by specific color values, typography specs, and component behaviors.
## Prerequisites
- Access to Google Stitch via [labs.google/stitch](https://labs.google/stitch)
- Optionally: Stitch MCP Server for programmatic integration with Cursor, Antigravity, or Gemini CLI
## The Goal
Generate a `DESIGN.md` file that encodes:
1. **Visual atmosphere** — the mood, density, and design philosophy
2. **Color calibration** — neutrals, accents, and banned patterns with hex codes
3. **Typographic architecture** — font stacks, scale hierarchy, and anti-patterns
4. **Component behaviors** — buttons, cards, inputs with interaction states
5. **Layout principles** — grid systems, spacing philosophy, responsive strategy
6. **Motion philosophy** — animation engine specs, spring physics, perpetual micro-interactions
7. **Anti-patterns** — explicit list of banned AI design clichés
## Analysis & Synthesis Instructions
### 1. Define the Atmosphere
Evaluate the target project's intent. Use evocative adjectives from the taste spectrum:
- **Density:** "Art Gallery Airy" (1–3) → "Daily App Balanced" (4–7) → "Cockpit Dense" (8–10)
- **Variance:** "Predictable Symmetric" (1–3) → "Offset Asymmetric" (4–7) → "Artsy Chaotic" (8–10)
- **Motion:** "Static Restrained" (1–3) → "Fluid CSS" (4–7) → "Cinematic Choreography" (8–10)
Default baseline: Variance 8, Motion 6, Density 4. Adapt dynamically based on user's vibe description.
### 2. Map the Color Palette
For each color provide: **Descriptive Name** + **Hex Code** + **Functional Role**.
**Mandatory constraints:**
- Maximum 1 accent color. Saturation below 80%
- The "AI Purple/Blue Neon" aesthetic is strictly BANNED — no purple button glows, no neon gradients
- Use absolute neutral bases (Zinc/Slate) with high-contrast singular accents
- Stick to one palette for the entire output — no warm/cool gray fluctuation
- Never use pure black (`#000000`) — use Off-Black, Zinc-950, or Charcoal
### 3. Establish Typography Rules
- **Display/Headlines:** Track-tight, controlled scale. Not screaming. Hierarchy through weight and color, not just massive size
- **Body:** Relaxed leading, max 65 characters per line
- **Font Selection:** `Inter` is BANNED for premium/creative contexts. Force unique character: `Geist`, `Outfit`, `Cabinet Grotesk`, or `Satoshi`
- **Serif Ban:** Generic serif fonts (`Times New Roman`, `Georgia`, `Garamond`, `Palatino`) are BANNED. If serif is needed for editorial/creative contexts, use only distinctive modern serifs: `Fraunces`, `Gambarino`, `Editorial New`, or `Instrument Serif`. Serif is always BANNED in dashboards or software UIs
- **Dashboard Constraint:** Use Sans-Serif pairings exclusively (`Geist` + `Geist Mono` or `Satoshi` + `JetBrains Mono`)
- **High-Density Override:** When density exceeds 7, all numbers must use Monospace
### 4. Define the Hero Section
The Hero is the first impression and must be creative, striking, and never generic:
- **Inline Image Typography:** Embed small, contextual photos or visuals directly between words or letters in the headline. Images sit inline at type-height, rounded, acting as visual punctuation. This is the signature creative technique
- **No Overlapping:** Text must never overlap images or other text. Every element occupies its own clean spatial zone
- **No Filler Text:** "Scroll to explore", "Swipe down", scroll arrow icons, bouncing chevrons are BANNED. The content should pull users in naturally
- **Asymmetric Structure:** Centered Hero layouts BANNED when variance exceeds 4
- **CTA Restraint:** Maximum one primary CTA. No secondary "Learn more" links
### 5. Describe Component Stylings
For each component type, describe shape, color, shadow depth, and interaction behavior:
- **Buttons:** Tactile push feedback on active state. No neon outer glows. No custom mouse cursors
- **Cards:** Use ONLY when elevation communicates hierarchy. Tint shadows to background hue. For high-density layouts, replace cards with border-top dividers or negative space
- **Inputs/Forms:** Label above input, helper text optional, error text below. Standard gap spacing
- **Loading States:** Skeletal loaders matching layout dimensions — no generic circular spinners
- **Empty States:** Composed compositions indicating how to populate data
- **Error States:** Clear, inline error reporting
### 6. Define Layout Principles
- No overlapping elements — every element occupies its own clear spatial zone. No absolute-positioned content stacking
- Centered Hero sections are BANNED when variance exceeds 4 — force Split Screen, Left-Aligned, or Asymmetric Whitespace
- The generic "3 equal cards horizontally" feature row is BANNED — use 2-column Zig-Zag, asymmetric grid, or horizontal scroll
- CSS Grid over Flexbox math — never use `calc()` percentage hacks
- Contain layouts using max-width constraints (e.g., 1400px centered)
- Full-height sections must use `min-h-[100dvh]` — never `h-screen` (iOS Safari catastrophic jump)
### 7. Define Responsive Rules
Every design must work across all viewports:
- **Mobile-First Collapse (< 768px):** All multi-column layouts collapse to single column. No exceptions
- **No Horizontal Scroll:** Horizontal overflow on mobile is a critical failure
- **Typography Scaling:** Headlines scale via `clamp()`. Body text minimum `1rem`/`14px`
- **Touch Targets:** All interactive elements minimum `44px` tap target
- **Image Behavior:** Inline typography images (photos between words) stack below headline on mobile
- **Navigation:** Desktop horizontal nav collapses to clean mobile menu
- **Spacing:** Vertical section gaps reduce proportionally (`clamp(3rem, 8vw, 6rem)`)
### 8. Encode Motion Philosophy
- **Spring Physics default:** `stiffness: 100, damping: 20` — premium, weighty feel. No linear easing
- **Perpetual Micro-Interactions:** Every active component should have an infinite loop state (Pulse, Typewriter, Float, Shimmer)
- **Staggered Orchestration:** Never mount lists instantly — use cascade delays for waterfall reveals
- **Performance:** Animate exclusively via `transform` and `opacity`. Never animate `top`, `left`, `width`, `height`. Grain/noise filters on fixed pseudo-elements only
### 9. List Anti-Patterns (AI Tells)
Encode these as explicit "NEVER DO" rules in the DESIGN.md:
- No emojis anywhere
- No `Inter` font
- No generic serif fonts (`Times New Roman`, `Georgia`, `Garamond`) — distinctive modern serifs only if needed
- No pure black (`#000000`)
- No neon/outer glow shadows
- No oversaturated accents
- No excessive gradient text on large headers
- No custom mouse cursors
- No overlapping elements — clean spatial separation always
- No 3-column equal card layouts
- No generic names ("John Doe", "Acme", "Nexus")
- No fake round numbers (`99.99%`, `50%`)
- No AI copywriting clichés ("Elevate", "Seamless", "Unleash", "Next-Gen")
- No filler UI text: "Scroll to explore", "Swipe down", scroll arrows, bouncing chevrons
- No broken Unsplash links — use `picsum.photos` or SVG avatars
- No centered Hero sections (for high-variance projects)
## Output Format (DESIGN.md Structure)
```markdown
# Design System: [Project Title]
## 1. Visual Theme & Atmosphere
(Evocative description of the mood, density, variance, and motion intensity.
Example: "A restrained, gallery-airy interface with confident asymmetric layouts
and fluid spring-physics motion. The atmosphere is clinical yet warm — like a
well-lit architecture studio.")
## 2. Color Palette & Roles
- **Canvas White** (#F9FAFB) — Primary background surface
- **Pure Surface** (#FFFFFF) — Card and container fill
- **Charcoal Ink** (#18181B) — Primary text, Zinc-950 depth
- **Muted Steel** (#71717A) — Secondary text, descriptions, metadata
- **Whisper Border** (rgba(226,232,240,0.5)) — Card borders, 1px structural lines
- **[Accent Name]** (#XXXXXX) — Single accent for CTAs, active states, focus rings
(Max 1 accent. Saturation < 80%. No purple/neon.)
## 3. Typography Rules
- **Display:** [Font Name] — Track-tight, controlled scale, weight-driven hierarchy
- **Body:** [Font Name] — Relaxed leading, 65ch max-width, neutral secondary color
- **Mono:** [Font Name] — For code, metadata, timestamps, high-density numbers
- **Banned:** Inter, generic system fonts for premium contexts. Serif fonts banned in dashboards.
## 4. Component Stylings
* **Buttons:** Flat, no outer glow. Tactile -1px translate on active. Accent fill for primary, ghost/outline for secondary.
* **Cards:** Generously rounded corners (2.5rem). Diffused whisper shadow. Used only when elevation serves hierarchy. High-density: replace with border-top dividers.
* **Inputs:** Label above, error below. Focus ring in accent color. No floating labels.
* **Loaders:** Skeletal shimmer matching exact layout dimensions. No circular spinners.
* **Empty States:** Composed, illustrated compositions — not just "No data" text.
## 5. Layout Principles
(Grid-first responsive architecture. Asymmetric splits for Hero sections.
Strict single-column collapse below 768px. Max-width containment.
No flexbox percentage math. Generous internal padding.)
## 6. Motion & Interaction
(Spring physics for all interactive elements. Staggered cascade reveals.
Perpetual micro-loops on active dashboard components. Hardware-accelerated
transforms only. Isolated Client Components for CPU-heavy animations.)
## 7. Anti-Patterns (Banned)
(Explicit list of forbidden patterns: no emojis, no Inter, no pure black,
no neon glows, no 3-column equal grids, no AI copywriting clichés,
no generic placeholder names, no broken image links.)
```
## Best Practices
- **Be Descriptive:** "Deep Charcoal Ink (#18181B)" — not just "dark text"
- **Be Functional:** Explain what each element is used for
- **Be Consistent:** Same terminology throughout the document
- **Be Precise:** Include exact hex codes, rem values, pixel values in parentheses
- **Be Opinionated:** This is not a neutral template — it enforces a specific, premium aesthetic
## Tips for Success
1. Start with the atmosphere — understand the vibe before detailing tokens
2. Look for patterns — identify consistent spacing, sizing, and styling
3. Think semantically — name colors by purpose, not just appearance
4. Consider hierarchy — document how visual weight communicates importance
5. Encode the bans — anti-patterns are as important as the rules themselves
## Common Pitfalls to Avoid
- Using technical jargon without translation ("rounded-xl" instead of "generously rounded corners")
- Omitting hex codes or using only descriptive names
- Forgetting functional roles of design elements
- Being too vague in atmosphere descriptions
- Ignoring the anti-pattern list — these are what make the output premium
- Defaulting to generic "safe" designs instead of enforcing the curated aesthetic
plugins/codex/plugins/taste-skill/skills/taste-skill-v1/SKILL.md
-226
View File
@@ -1,226 +0,0 @@
---
name: design-taste-frontend-v1
description: "Taste Skill v1 兼容版本，用于需要保持原始行为的项目。"
---
# High-Agency Frontend Skill
## 1. ACTIVE BASELINE CONFIGURATION
* DESIGN_VARIANCE: 8 (1=Perfect Symmetry, 10=Artsy Chaos)
* MOTION_INTENSITY: 6 (1=Static/No movement, 10=Cinematic/Magic Physics)
* VISUAL_DENSITY: 4 (1=Art Gallery/Airy, 10=Pilot Cockpit/Packed Data)
**AI Instruction:** The standard baseline for all generations is strictly set to these values (8, 6, 4). Do not ask the user to edit this file. Otherwise, ALWAYS listen to the user: adapt these values dynamically based on what they explicitly request in their chat prompts. Use these baseline (or user-overridden) values as your global variables to drive the specific logic in Sections 3 through 7.
## 2. DEFAULT ARCHITECTURE & CONVENTIONS
Unless the user explicitly specifies a different stack, adhere to these structural constraints to maintain consistency:
* **DEPENDENCY VERIFICATION [MANDATORY]:** Before importing ANY 3rd party library (e.g. `framer-motion`, `lucide-react`, `zustand`), you MUST check `package.json`. If the package is missing, you MUST output the installation command (e.g. `npm install package-name`) before providing the code. **Never** assume a library exists.
* **Framework & Interactivity:** React or Next.js. Default to Server Components (`RSC`).
* **RSC SAFETY:** Global state works ONLY in Client Components. In Next.js, wrap providers in a `"use client"` component.
* **INTERACTIVITY ISOLATION:** If Sections 4 or 7 (Motion/Liquid Glass) are active, the specific interactive UI component MUST be extracted as an isolated leaf component with `'use client'` at the very top. Server Components must exclusively render static layouts.
* **State Management:** Use local `useState`/`useReducer` for isolated UI. Use global state strictly for deep prop-drilling avoidance.
* **Styling Policy:** Use Tailwind CSS (v3/v4) for 90% of styling.
* **TAILWIND VERSION LOCK:** Check `package.json` first. Do not use v4 syntax in v3 projects.
* **T4 CONFIG GUARD:** For v4, do NOT use `tailwindcss` plugin in `postcss.config.js`. Use `@tailwindcss/postcss` or the Vite plugin.
* **ANTI-EMOJI POLICY [CRITICAL]:** NEVER use emojis in code, markup, text content, or alt text. Replace symbols with high-quality icons (Radix, Phosphor) or clean SVG primitives. Emojis are BANNED.
* **Responsiveness & Spacing:**
* Standardize breakpoints (`sm`, `md`, `lg`, `xl`).
* Contain page layouts using `max-w-[1400px] mx-auto` or `max-w-7xl`.
* **Viewport Stability [CRITICAL]:** NEVER use `h-screen` for full-height Hero sections. ALWAYS use `min-h-[100dvh]` to prevent catastrophic layout jumping on mobile browsers (iOS Safari).
* **Grid over Flex-Math:** NEVER use complex flexbox percentage math (`w-[calc(33%-1rem)]`). ALWAYS use CSS Grid (`grid grid-cols-1 md:grid-cols-3 gap-6`) for reliable structures.
* **Icons:** You MUST use exactly `@phosphor-icons/react` or `@radix-ui/react-icons` as the import paths (check installed version). Standardize `strokeWidth` globally (e.g., exclusively use `1.5` or `2.0`).
## 3. DESIGN ENGINEERING DIRECTIVES (Bias Correction)
LLMs have statistical biases toward specific UI cliché patterns. Proactively construct premium interfaces using these engineered rules:
**Rule 1: Deterministic Typography**
* **Display/Headlines:** Default to `text-4xl md:text-6xl tracking-tighter leading-none`.
* **ANTI-SLOP:** Discourage `Inter` for "Premium" or "Creative" vibes. Force unique character using `Geist`, `Outfit`, `Cabinet Grotesk`, or `Satoshi`.
* **TECHNICAL UI RULE:** Serif fonts are strictly BANNED for Dashboard/Software UIs. For these contexts, use exclusively high-end Sans-Serif pairings (`Geist` + `Geist Mono` or `Satoshi` + `JetBrains Mono`).
* **Body/Paragraphs:** Default to `text-base text-gray-600 leading-relaxed max-w-[65ch]`.
**Rule 2: Color Calibration**
* **Constraint:** Max 1 Accent Color. Saturation < 80%.
* **THE LILA BAN:** The "AI Purple/Blue" aesthetic is strictly BANNED. No purple button glows, no neon gradients. Use absolute neutral bases (Zinc/Slate) with high-contrast, singular accents (e.g. Emerald, Electric Blue, or Deep Rose).
* **COLOR CONSISTENCY:** Stick to one palette for the entire output. Do not fluctuate between warm and cool grays within the same project.
**Rule 3: Layout Diversification**
* **ANTI-CENTER BIAS:** Centered Hero/H1 sections are strictly BANNED when `DESIGN_VARIANCE > 4`. Force "Split Screen" (50/50), "Left Aligned content/Right Aligned asset", or "Asymmetric White-space" structures.
**Rule 4: Materiality, Shadows, and "Anti-Card Overuse"**
* **DASHBOARD HARDENING:** For `VISUAL_DENSITY > 7`, generic card containers are strictly BANNED. Use logic-grouping via `border-t`, `divide-y`, or purely negative space. Data metrics should breathe without being boxed in unless elevation (z-index) is functionally required.
* **Execution:** Use cards ONLY when elevation communicates hierarchy. When a shadow is used, tint it to the background hue.
**Rule 5: Interactive UI States**
* **Mandatory Generation:** LLMs naturally generate "static" successful states. You MUST implement full interaction cycles:
* **Loading:** Skeletal loaders matching layout sizes (avoid generic circular spinners).
* **Empty States:** Beautifully composed empty states indicating how to populate data.
* **Error States:** Clear, inline error reporting (e.g., forms).
* **Tactile Feedback:** On `:active`, use `-translate-y-[1px]` or `scale-[0.98]` to simulate a physical push indicating success/action.
**Rule 6: Data & Form Patterns**
* **Forms:** Label MUST sit above input. Helper text is optional but should exist in markup. Error text below input. Use a standard `gap-2` for input blocks.
## 4. CREATIVE PROACTIVITY (Anti-Slop Implementation)
To actively combat generic AI designs, systematically implement these high-end coding concepts as your baseline:
* **"Liquid Glass" Refraction:** When glassmorphism is needed, go beyond `backdrop-blur`. Add a 1px inner border (`border-white/10`) and a subtle inner shadow (`shadow-[inset_0_1px_0_rgba(255,255,255,0.1)]`) to simulate physical edge refraction.
* **Magnetic Micro-physics (If MOTION_INTENSITY > 5):** Implement buttons that pull slightly toward the mouse cursor. **CRITICAL:** NEVER use React `useState` for magnetic hover or continuous animations. Use EXCLUSIVELY Framer Motion's `useMotionValue` and `useTransform` outside the React render cycle to prevent performance collapse on mobile.
* **Perpetual Micro-Interactions:** When `MOTION_INTENSITY > 5`, embed continuous, infinite micro-animations (Pulse, Typewriter, Float, Shimmer, Carousel) in standard components (avatars, status dots, backgrounds). Apply premium Spring Physics (`type: "spring", stiffness: 100, damping: 20`) to all interactive elements—no linear easing.
* **Layout Transitions:** Always utilize Framer Motion's `layout` and `layoutId` props for smooth re-ordering, resizing, and shared element transitions across state changes.
* **Staggered Orchestration:** Do not mount lists or grids instantly. Use `staggerChildren` (Framer) or CSS cascade (`animation-delay: calc(var(--index) * 100ms)`) to create sequential waterfall reveals. **CRITICAL:** For `staggerChildren`, the Parent (`variants`) and Children MUST reside in the identical Client Component tree. If data is fetched asynchronously, pass the data as props into a centralized Parent Motion wrapper.
## 5. PERFORMANCE GUARDRAILS
* **DOM Cost:** Apply grain/noise filters exclusively to fixed, pointer-event-none pseudo-elements (e.g., `fixed inset-0 z-50 pointer-events-none`) and NEVER to scrolling containers to prevent continuous GPU repaints and mobile performance degradation.
* **Hardware Acceleration:** Never animate `top`, `left`, `width`, or `height`. Animate exclusively via `transform` and `opacity`.
* **Z-Index Restraint:** NEVER spam arbitrary `z-50` or `z-10` unprompted. Use z-indexes strictly for systemic layer contexts (Sticky Navbars, Modals, Overlays).
## 6. TECHNICAL REFERENCE (Dial Definitions)
### DESIGN_VARIANCE (Level 1-10)
* **1-3 (Predictable):** Flexbox `justify-center`, strict 12-column symmetrical grids, equal paddings.
* **4-7 (Offset):** Use `margin-top: -2rem` overlapping, varied image aspect ratios (e.g., 4:3 next to 16:9), left-aligned headers over center-aligned data.
* **8-10 (Asymmetric):** Masonry layouts, CSS Grid with fractional units (e.g., `grid-template-columns: 2fr 1fr 1fr`), massive empty zones (`padding-left: 20vw`).
* **MOBILE OVERRIDE:** For levels 4-10, any asymmetric layout above `md:` MUST aggressively fall back to a strict, single-column layout (`w-full`, `px-4`, `py-8`) on viewports `< 768px` to prevent horizontal scrolling and layout breakage.
### MOTION_INTENSITY (Level 1-10)
* **1-3 (Static):** No automatic animations. CSS `:hover` and `:active` states only.
* **4-7 (Fluid CSS):** Use `transition: all 0.3s cubic-bezier(0.16, 1, 0.3, 1)`. Use `animation-delay` cascades for load-ins. Focus strictly on `transform` and `opacity`. Use `will-change: transform` sparingly.
* **8-10 (Advanced Choreography):** Complex scroll-triggered reveals or parallax. Use Framer Motion hooks. NEVER use `window.addEventListener('scroll')`.
### VISUAL_DENSITY (Level 1-10)
* **1-3 (Art Gallery Mode):** Lots of white space. Huge section gaps. Everything feels very expensive and clean.
* **4-7 (Daily App Mode):** Normal spacing for standard web apps.
* **8-10 (Cockpit Mode):** Tiny paddings. No card boxes; just 1px lines to separate data. Everything is packed. **Mandatory:** Use Monospace (`font-mono`) for all numbers.
## 7. AI TELLS (Forbidden Patterns)
To guarantee a premium, non-generic output, you MUST strictly avoid these common AI design signatures unless explicitly requested:
### Visual & CSS
* **NO Neon/Outer Glows:** Do not use default `box-shadow` glows or auto-glows. Use inner borders or subtle tinted shadows.
* **NO Pure Black:** Never use `#000000`. Use Off-Black, Zinc-950, or Charcoal.
* **NO Oversaturated Accents:** Desaturate accents to blend elegantly with neutrals.
* **NO Excessive Gradient Text:** Do not use text-fill gradients for large headers.
* **NO Custom Mouse Cursors:** They are outdated and ruin performance/accessibility.
### Typography
* **NO Inter Font:** Banned. Use `Geist`, `Outfit`, `Cabinet Grotesk`, or `Satoshi`.
* **NO Oversized H1s:** The first heading should not scream. Control hierarchy with weight and color, not just massive scale.
* **Serif Constraints:** Use Serif fonts ONLY for creative/editorial designs. **NEVER** use Serif on clean Dashboards.
### Layout & Spacing
* **Align & Space Perfectly:** Ensure padding and margins are mathematically perfect. Avoid floating elements with awkward gaps.
* **NO 3-Column Card Layouts:** The generic "3 equal cards horizontally" feature row is BANNED. Use a 2-column Zig-Zag, asymmetric grid, or horizontal scrolling approach instead.
### Content & Data (The "Jane Doe" Effect)
* **NO Generic Names:** "John Doe", "Sarah Chan", or "Jack Su" are banned. Use highly creative, realistic-sounding names.
* **NO Generic Avatars:** DO NOT use standard SVG "egg" or Lucide user icons for avatars. Use creative, believable photo placeholders or specific styling.
* **NO Fake Numbers:** Avoid predictable outputs like `99.99%`, `50%`, or basic phone numbers (`1234567`). Use organic, messy data (`47.2%`, `+1 (312) 847-1928`).
* **NO Startup Slop Names:** "Acme", "Nexus", "SmartFlow". Invent premium, contextual brand names.
* **NO Filler Words:** Avoid AI copywriting clichés like "Elevate", "Seamless", "Unleash", or "Next-Gen". Use concrete verbs.
### External Resources & Components
* **NO Broken Unsplash Links:** Do not use Unsplash. Use absolute, reliable placeholders like `https://picsum.photos/seed/{random_string}/800/600` or SVG UI Avatars.
* **shadcn/ui Customization:** You may use `shadcn/ui`, but NEVER in its generic default state. You MUST customize the radii, colors, and shadows to match the high-end project aesthetic.
* **Production-Ready Cleanliness:** Code must be extremely clean, visually striking, memorable, and meticulously refined in every detail.
## 8. THE CREATIVE ARSENAL (High-End Inspiration)
Do not default to generic UI. Pull from this library of advanced concepts to ensure the output is visually striking and memorable. When appropriate, leverage **GSAP (ScrollTrigger/Parallax)** for complex scrolltelling or **ThreeJS/WebGL** for 3D/Canvas animations, rather than basic CSS motion. **CRITICAL:** Never mix GSAP/ThreeJS with Framer Motion in the same component tree. Default to Framer Motion for UI/Bento interactions. Use GSAP/ThreeJS EXCLUSIVELY for isolated full-page scrolltelling or canvas backgrounds, wrapped in strict useEffect cleanup blocks.
### The Standard Hero Paradigm
* Stop doing centered text over a dark image. Try asymmetric Hero sections: Text cleanly aligned to the left or right. The background should feature a high-quality, relevant image with a subtle stylistic fade (darkening or lightening gracefully into the background color depending on if it is Light or Dark mode).
### Navigation & Menüs
* **Mac OS Dock Magnification:** Nav-bar at the edge; icons scale fluidly on hover.
* **Magnetic Button:** Buttons that physically pull toward the cursor.
* **Gooey Menu:** Sub-items detach from the main button like a viscous liquid.
* **Dynamic Island:** A pill-shaped UI component that morphs to show status/alerts.
* **Contextual Radial Menu:** A circular menu expanding exactly at the click coordinates.
* **Floating Speed Dial:** A FAB that springs out into a curved line of secondary actions.
* **Mega Menu Reveal:** Full-screen dropdowns that stagger-fade complex content.
### Layout & Grids
* **Bento Grid:** Asymmetric, tile-based grouping (e.g., Apple Control Center).
* **Masonry Layout:** Staggered grid without fixed row heights (e.g., Pinterest).
* **Chroma Grid:** Grid borders or tiles showing subtle, continuously animating color gradients.
* **Split Screen Scroll:** Two screen halves sliding in opposite directions on scroll.
* **Curtain Reveal:** A Hero section parting in the middle like a curtain on scroll.
### Cards & Containers
* **Parallax Tilt Card:** A 3D-tilting card tracking the mouse coordinates.
* **Spotlight Border Card:** Card borders that illuminate dynamically under the cursor.
* **Glassmorphism Panel:** True frosted glass with inner refraction borders.
* **Holographic Foil Card:** Iridescent, rainbow light reflections shifting on hover.
* **Tinder Swipe Stack:** A physical stack of cards the user can swipe away.
* **Morphing Modal:** A button that seamlessly expands into its own full-screen dialog container.
### Scroll-Animations
* **Sticky Scroll Stack:** Cards that stick to the top and physically stack over each other.
* **Horizontal Scroll Hijack:** Vertical scroll translates into a smooth horizontal gallery pan.
* **Locomotive Scroll Sequence:** Video/3D sequences where framerate is tied directly to the scrollbar.
* **Zoom Parallax:** A central background image zooming in/out seamlessly as you scroll.
* **Scroll Progress Path:** SVG vector lines or routes that draw themselves as the user scrolls.
* **Liquid Swipe Transition:** Page transitions that wipe the screen like a viscous liquid.
### Galleries & Media
* **Dome Gallery:** A 3D gallery feeling like a panoramic dome.
* **Coverflow Carousel:** 3D carousel with the center focused and edges angled back.
* **Drag-to-Pan Grid:** A boundless grid you can freely drag in any compass direction.
* **Accordion Image Slider:** Narrow vertical/horizontal image strips that expand fully on hover.
* **Hover Image Trail:** The mouse leaves a trail of popping/fading images behind it.
* **Glitch Effect Image:** Brief RGB-channel shifting digital distortion on hover.
### Typography & Text
* **Kinetic Marquee:** Endless text bands that reverse direction or speed up on scroll.
* **Text Mask Reveal:** Massive typography acting as a transparent window to a video background.
* **Text Scramble Effect:** Matrix-style character decoding on load or hover.
* **Circular Text Path:** Text curved along a spinning circular path.
* **Gradient Stroke Animation:** Outlined text with a gradient continuously running along the stroke.
* **Kinetic Typography Grid:** A grid of letters dodging or rotating away from the cursor.
### Micro-Interactions & Effects
* **Particle Explosion Button:** CTAs that shatter into particles upon success.
* **Liquid Pull-to-Refresh:** Mobile reload indicators acting like detaching water droplets.
* **Skeleton Shimmer:** Shifting light reflections moving across placeholder boxes.
* **Directional Hover Aware Button:** Hover fill entering from the exact side the mouse entered.
* **Ripple Click Effect:** Visual waves rippling precisely from the click coordinates.
* **Animated SVG Line Drawing:** Vectors that draw their own contours in real-time.
* **Mesh Gradient Background:** Organic, lava-lamp-like animated color blobs.
* **Lens Blur Depth:** Dynamic focus blurring background UI layers to highlight a foreground action.
## 9. THE "MOTION-ENGINE" BENTO PARADIGM
When generating modern SaaS dashboards or feature sections, you MUST utilize the following "Bento 2.0" architecture and motion philosophy. This goes beyond static cards and enforces a "Vercel-core meets Dribbble-clean" aesthetic heavily reliant on perpetual physics.
### A. Core Design Philosophy
* **Aesthetic:** High-end, minimal, and functional.
* **Palette:** Background in `#f9fafb`. Cards are pure white (`#ffffff`) with a 1px border of `border-slate-200/50`.
* **Surfaces:** Use `rounded-[2.5rem]` for all major containers. Apply a "diffusion shadow" (a very light, wide-spreading shadow, e.g., `shadow-[0_20px_40px_-15px_rgba(0,0,0,0.05)]`) to create depth without clutter.
* **Typography:** Strict `Geist`, `Satoshi`, or `Cabinet Grotesk` font stack. Use subtle tracking (`tracking-tight`) for headers.
* **Labels:** Titles and descriptions must be placed **outside and below** the cards to maintain a clean, gallery-style presentation.
* **Pixel-Perfection:** Use generous `p-8` or `p-10` padding inside cards.
### B. The Animation Engine Specs (Perpetual Motion)
All cards must contain **"Perpetual Micro-Interactions."** Use the following Framer Motion principles:
* **Spring Physics:** No linear easing. Use `type: "spring", stiffness: 100, damping: 20` for a premium, weighty feel.
* **Layout Transitions:** Heavily utilize the `layout` and `layoutId` props to ensure smooth re-ordering, resizing, and shared element state transitions.
* **Infinite Loops:** Every card must have an "Active State" that loops infinitely (Pulse, Typewriter, Float, or Carousel) to ensure the dashboard feels "alive".
* **Performance:** Wrap dynamic lists in `<AnimatePresence>` and optimize for 60fps. **PERFORMANCE CRITICAL:** Any perpetual motion or infinite loop MUST be memoized (React.memo) and completely isolated in its own microscopic Client Component. Never trigger re-renders in the parent layout.
### C. The 5-Card Archetypes (Micro-Animation Specs)
Implement these specific micro-animations when constructing Bento grids (e.g., Row 1: 3 cols | Row 2: 2 cols split 70/30):
1. **The Intelligent List:** A vertical stack of items with an infinite auto-sorting loop. Items swap positions using `layoutId`, simulating an AI prioritizing tasks in real-time.
2. **The Command Input:** A search/AI bar with a multi-step Typewriter Effect. It cycles through complex prompts, including a blinking cursor and a "processing" state with a shimmering loading gradient.
3. **The Live Status:** A scheduling interface with "breathing" status indicators. Include a pop-up notification badge that emerges with an "Overshoot" spring effect, stays for 3 seconds, and vanishes.
4. **The Wide Data Stream:** A horizontal "Infinite Carousel" of data cards or metrics. Ensure the loop is seamless (using `x: ["0%", "-100%"]`) with a speed that feels effortless.
5. **The Contextual UI (Focus Mode):** A document view that animates a staggered highlight of a text block, followed by a "Float-in" of a floating action toolbar with micro-icons.
## 10. FINAL PRE-FLIGHT CHECK
Evaluate your code against this matrix before outputting. This is the **last** filter you apply to your logic.
- [ ] Is global state used appropriately to avoid deep prop-drilling rather than arbitrarily?
- [ ] Is mobile layout collapse (`w-full`, `px-4`, `max-w-7xl mx-auto`) guaranteed for high-variance designs?
- [ ] Do full-height sections safely use `min-h-[100dvh]` instead of the bugged `h-screen`?
- [ ] Do `useEffect` animations contain strict cleanup functions?
- [ ] Are empty, loading, and error states provided?
- [ ] Are cards omitted in favor of spacing where possible?
- [ ] Did you strictly isolate CPU-heavy perpetual animations in their own Client Components?
plugins/codex/plugins/taste-skill/skills/taste-skill-v2-experimental/SKILL.md
-1228
View File
File diff suppressed because it is too large. Load diff
plugins/codex/plugins/taste-skill/skills/taste-skill/SKILL.md
+120 -15
View File
@@ -31,6 +31,34 @@ In the commands below `<skill>` is this skill's folder. Run them from the projec
working files land in `.taste-skill/` there. The scripts need Node 22+ and an installed Chrome, Edge working files land in `.taste-skill/` there. The scripts need Node 22+ and an installed Chrome, Edge
or Chromium, and install nothing. `assets.mjs` also needs network access; it uses no API keys. or Chromium, and install nothing. `assets.mjs` also needs network access; it uses no API keys.
## Page or app screen
Decide first which of two kinds of work this is.
- **A page** is read and scrolled: a landing page, a marketing or product site, a portfolio, an
event, a restaurant, a one-pager. It follows **the run** below.
- **An app screen** is worked in: a dashboard, an admin or analytics view, settings, billing, an inbox
or queue to work through, a wallet, a list with filters, an editor or builder. It follows
**`references/app-screens.md`**: its own run, its own draw (`draw.mjs --app`), its own house rules
(quiet borders, small labels and repeated panels are normal there; gradients, glows, icons in tinted
squares, rainbow charts and invented vanity numbers are not) and `inspect.mjs --app`. Read that file
whole before you start; the page run below does not apply.
A product site that shows its app is a page; the interface fragments on it follow the app-screen
rules for their insides. Deal the product's app style once, in its own folder, with the page's colours
and type kept:
```bash
node <skill>/scripts/draw.mjs --app --kind <kind> --brief "<the product>" --keep palette,type --out .taste-skill/app
```
and build every fragment the page shows (the hero's live screen, a feature's crop, a chart) as a real
piece of that app: `assets/app.css` for its panels, tables and controls, `assets/charts.js` for its
charts, real data that adds up, one finding stated, cropped and scaled the way the page's blueprint
treats a picture. A fragment that looks like a working product is the strongest picture a software page
has; grey bars and lorem numbers are the weakest. When a request mixes both (a landing page and the
dashboard behind it), build each with its own run and one shared palette and typeface.
## The run ## The run
Do these in order. Steps 1–5 take a few minutes and decide whether the page is any good. Do these in order. Steps 1–5 take a few minutes and decide whether the page is any good.
@@ -102,7 +130,7 @@ The command prints a **direction sheet**. It is the art direction for this build
- **Adopt it.** Do not blend it with the layout you would have made anyway. If it feels unfamiliar, - **Adopt it.** Do not blend it with the layout you would have made anyway. If it feels unfamiliar,
good: the familiar layout is the one this skill exists to prevent. good: the familiar layout is the one this skill exists to prevent.
- Redraw one slot (`--redraw hero | type | palette | photos | section:<role> | direction`) only for a - Redraw one slot (`--redraw hero | type | palette | photos | scenes | section:<role> | direction`) only for a
reason you can state: it contradicts a stated brand constraint, or needs an asset that does not reason you can state: it contradicts a stated brand constraint, or needs an asset that does not
exist. Never redraw to get something more comfortable. Record every redraw in your report. exist. Never redraw to get something more comfortable. Record every redraw in your report.
- When a dealt section cannot hold the real content (it compares three plans and there is one price; - When a dealt section cannot hold the real content (it compares three plans and there is one price;
@@ -153,6 +181,12 @@ right now and how long until the last ferry; choose a size and see it against th
fallback without script, it never blocks reading, and it is one thing, not a playground. It is fallback without script, it never blocks reading, and it is one thing, not a playground. It is
built in step 6 as part of the page, not added as motion in step 9. built in step 6 as part of the page, not added as motion in step 9.
**The scenes carry the idea too.** The scroll scenes on the sheet are devices waiting for a subject.
Decide what each one shows from your inventory before building: the fly-through passes through this
studio's own title cards, the route is the road this shipment really takes, the picture that opens to
the whole screen is the room the guest will wake up in. A scene filled with pictures that could belong
to anyone is a screensaver.
### 5. Write the words ### 5. Write the words
Write the whole page as a copy deck (plain text) before markup, following `references/copy.md`: Write the whole page as a copy deck (plain text) before markup, following `references/copy.md`:
@@ -160,8 +194,10 @@ Write the whole page as a copy deck (plain text) before markup, following `refer
- **Every headline fits in two lines or fewer at every width.** Do the arithmetic in copy.md §2 before - **Every headline fits in two lines or fewer at every width.** Do the arithmetic in copy.md §2 before
committing to a sentence: about 32 characters is safe everywhere at a confident size. The studied committing to a sentence: about 32 characters is safe everywhere at a confident size. The studied
gallery heroes have a median of 5 words and 32 characters. gallery heroes have a median of 5 words and 32 characters.
- One supporting sentence. One primary action, named for what it does, as a real button on the first - One supporting sentence, directly under the headline (32–48px below it) and shown with it, never
screen. docked at the foot of the first screen or held back by an animation. When the headline is a name or
a figure of speech, this sentence says plainly what the thing is. One primary action, named for what
it does, as a real button on the first screen.
- **The first screen answers the visitor's first question in large type.** For an event: what it is, - **The first screen answers the visitor's first question in large type.** For an event: what it is,
when and where (the dates belong in the headline or at the second size, never only in small text). when and where (the dates belong in the headline or at the second size, never only in small text).
For a product: what it is and what it costs or does. For a person: who and what they do. Every For a product: what it is and what it costs or does. For a person: who and what they do. Every
@@ -211,6 +247,13 @@ not finished. Order of work:
sea house), never as a stand-in for the subject; sea house), never as a stand-in for the subject;
6. type and colour alone. 6. type and colour alone.
When the project has footage or a real picture of its own process or product, the first screen
shows it, large (about 40% of the screen or more). Never write a sentence on the page about where
the pictures come from or what they are not ("none of these shows our bar"): a caption says what
the picture is, and the credit line sits small in the footer. A portfolio whose work is invented
for the brief draws each piece as a finished still of that work (its title card with its own type,
an end frame, a poster), with real detail, never as a pictogram of the client's product.
**The floor, which the inspector checks:** at least four real pictures on the page, usually six to **The floor, which the inspector checks:** at least four real pictures on the page, usually six to
twelve (photographs, archival images, maps, engravings, footage, raster artwork; for software, its twelve (photographs, archival images, maps, engravings, footage, raster artwork; for software, its
cropped interface fragments count too). SVG drawings do not count toward the floor: draw what no cropped interface fragments count too). SVG drawings do not count toward the floor: draw what no
@@ -221,11 +264,28 @@ not finished. Order of work:
`references/imagery.md` covers searching, licences and credits, video, drawing, crops and treatments. `references/imagery.md` covers searching, licences and credits, video, drawing, crops and treatments.
5. **The live thing** from step 4, built into the section where it proves the claim (often the hero 5. **The live thing** from step 4, built into the section where it proves the claim (often the hero
or the booking), with real content, a thumb-sized phone version and a plain fallback. or the booking), with real content, a thumb-sized phone version and a plain fallback.
6. **Fullness.** Look at each desktop screen as a poster: one dominant thing and the content it 6. **The scroll scenes,** when the sheet deals them (section 9), each with the section it carries: the page's big
moments, the camera that flies through the work, the picture that opens to the whole screen, the
word that buckles under the scroll. Copy the shared stage and the scene's files from
`<skill>/assets/scenes/`, fill the scene with this project's own pictures and words, and set the
page's tokens so it takes the page's look. A scene is composition: it decides how long the page is
and what each screen shows, so it is built now and seen in every look round, not added at the end.
`references/scenes.md` says how to put one on a page, fill it, fit it and check it;
`assets/scenes/demo/<id>.html` is a working example of each.
7. **Fullness.** Look at each desktop screen as a poster: one dominant thing and the content it
carries. A screen that is mostly empty ground is an underbuilt section, not a rest; one deliberate carries. A screen that is mostly empty ground is an underbuilt section, not a rest; one deliberate
rest per page is the limit, and the inspector fails a page with two or more near-empty screens. rest per page is the limit, and the inspector fails a page with two or more near-empty screens.
Running text is in the full ink at 16px or more; grey is for secondary notes. Running text is in the full ink at 16px or more; grey is for secondary notes.
7. **States and semantics.** Real links and buttons, visible focus, alt text, a phone layout that is 8. **The frame.** The page has one pair of equal outer margins at every width, and every section uses
the width the page has set up: when its text sits in the left half, the right half holds its
picture, its second column, its list or its figure, never nothing. Asymmetry lives inside the grid,
never in the frame: a void is placed only when something closes it on the far side. No stretch of
the page taller than about half a screen holds nothing at all; sections are 120–240px apart on
desktop. Every section the visitor came for opens with a heading that names it, and the first
screen carries the page's title in an `h1`. These are what readers name first when a page looks
wrong ("no clear title", "random empty space", "everything is pushed to one side"), and the
inspector measures each of them.
9. **States and semantics.** Real links and buttons, visible focus, alt text, a phone layout that is
its own composition. its own composition.
Read `references/type.md`, `references/colour.md` and `references/layout.md` when you need the detail Read `references/type.md`, `references/colour.md` and `references/layout.md` when you need the detail
@@ -236,12 +296,18 @@ behind a decision; the laws below are the short form.
```bash ```bash
node <skill>/scripts/lint.mjs <source files or folder> node <skill>/scripts/lint.mjs <source files or folder>
node <skill>/scripts/inspect.mjs <url or path/to/index.html> node <skill>/scripts/inspect.mjs <url or path/to/index.html>
node <skill>/scripts/scenes.mjs <url or path/to/index.html> # when the page has scroll scenes
``` ```
`scenes.mjs` photographs every scroll scene at 0, 10 … 100% of its hold, on desktop and on a phone,
and the reduced-motion page; with scenes on the sheet, `inspect.mjs` also films the whole scroll
(`desktop-film-NN.jpg`). A scene that never started or rests on desktop is a `FAIL`.
`lint.mjs` scans source for banned patterns and stock phrases. `inspect.mjs` opens the page in a real `lint.mjs` scans source for banned patterns and stock phrases. `inspect.mjs` opens the page in a real
browser at 1440, 768 and 390 pixels, measures it (headline line counts, type sizes, fonts actually browser at 1440, 768 and 390 pixels, measures it (headline line counts, type sizes, fonts actually
loaded, colours, rules, shadows, gradients, contrast, overflow) and saves screenshots to loaded, colours, rules, shadows, gradients, contrast, overflow, and the frame: equal margins, sections
`.taste-skill/inspect/`. Fix every `FAIL`. Treat each `WARN` as wrong unless you can defend it to a huddled on one side, blank stretches, the title, untitled sections, text against the screen edge) and
saves screenshots to `.taste-skill/inspect/`. Fix every `FAIL`. Treat each `WARN` as wrong unless you can defend it to a
designer in one sentence. Re-run until there are no `FAIL`s. Do not argue with the meter and do not designer in one sentence. Re-run until there are no `FAIL`s. Do not argue with the meter and do not
hide things from it. The inspector serves local files over a throwaway local server; if the page must hide things from it. The inspector serves local files over a throwaway local server; if the page must
also open straight from the file system, open `index.html` that way once before you finish. also open straight from the file system, open `index.html` that way once before you finish.
@@ -260,9 +326,9 @@ Judge only the pictures. If a problem is visible in a screenshot, it is real, wh
Now build the motion layer. It is required, and it is more than one fade: the inspector counts the Now build the motion layer. It is required, and it is more than one fade: the inspector counts the
elements that really move while the page loads and is scrolled, and fails a page under eight (it warns elements that really move while the page loads and is scrolled, and fails a page under eight (it warns
under sixteen). The layer has four parts: under sixteen). Any scroll scenes are already built (step 6); around them the layer has four parts:
1. **The signature move** named on the sheet: one, done well. 1. **The signature move** named on the sheet: one, done well (a dealt scene can be it).
2. **An entrance for the parts of every section:** the heading, then the text, then the picture, 2. **An entrance for the parts of every section:** the heading, then the text, then the picture,
staggered by 60–90ms, rising 16–32px with opacity, triggered once as the section enters. Not one staggered by 60–90ms, rising 16–32px with opacity, triggered once as the section enters. Not one
fade for the whole block, and never content that stays hidden if the script fails. fade for the whole block, and never content that stays hidden if the script fails.
@@ -278,6 +344,16 @@ every screenshot for content that failed to appear.
### 10. Report ### 10. Report
Do not report until all of these are true; each one was skipped in a test run that came out badly:
- `inspect.mjs` shows **0 FAIL** at 1440, 768 and 390, on the final version of the page.
- You opened every screenshot it listed after the last change, not only the first screen.
- With scroll scenes: `scenes.mjs` ran on the final page with no problems, and you read every sheet
(desktop, phone, reduced motion).
- A stranger reading the first screen for five seconds can say what this is and what to do.
- Every section has a heading; the margins match on both sides; no stretch of the page is empty.
- The critique of your last round is written down in the shape of `references/critique.md` §4.
Tell the user, briefly: the direction dealt (name and seed) and any redraws with reasons; the idea Tell the user, briefly: the direction dealt (name and seed) and any redraws with reasons; the idea
sentence and the live thing; the final scores from your last critique round and what still falls short; sentence and the live thing; the final scores from your last critique round and what still falls short;
every found picture and clip with its title, creator, licence and source page (`assets.mjs --credits` prints every found picture and clip with its title, creator, licence and source page (`assets.mjs --credits` prints
@@ -292,6 +368,9 @@ These hold on every build, whatever the direction. `inspect.mjs` measures them.
| Rule | Instead | | Rule | Instead |
| --- | --- | | --- | --- |
| **Headlines: two lines or fewer, at every width.** Every `h1`–`h6`, and the main line of the first screen whatever its tag. | Cut words. Then widen the measure. Size last. | | **Headlines: two lines or fewer, at every width.** Every `h1`–`h6`, and the main line of the first screen whatever its tag. | Cut words. Then widen the measure. Size last. |
| **A clear title on the first screen**, in the page's one `h1`, and a heading on every section. | Say what this is: the name with what it does, the product with what it is for, the event with its date and place. |
| **Equal outer margins; no section huddled on one side** with the other half of the screen empty. | Close every void with something on its far side: the section's picture, a second column, a list, a figure. |
| **No blank stretches** taller than about half a screen. | The normal section gap. A deliberate rest is a placed picture or a field of colour, once per page. |
| **Statements are paragraphs.** An intro sentence or a quotation set large is marked up as `<p>` or `<blockquote>`, stays at statement size (36px or less on desktop, 24px on a phone) and runs to about 25 words, three lines. | Larger than that it is a headline and the two-line rule applies. In blind tests jurors read a 42px sentence over four lines as a four-line headline. | | **Statements are paragraphs.** An intro sentence or a quotation set large is marked up as `<p>` or `<blockquote>`, stays at statement size (36px or less on desktop, 24px on a phone) and runs to about 25 words, three lines. | Larger than that it is a headline and the two-line rule applies. In blind tests jurors read a 42px sentence over four lines as a four-line headline. |
| **No eyebrows.** No small label above a heading, no pill badge above the headline, no "New ·" chip. | Put the information in the heading or the first sentence, or drop it. | | **No eyebrows.** No small label above a heading, no pill badge above the headline, no "New ·" chip. | Put the information in the heading or the first sentence, or drop it. |
| **No monospace** outside real code blocks. | The text face. Tabular figures where numbers align. | | **No monospace** outside real code blocks. | The text face. Tabular figures where numbers align. |
@@ -341,7 +420,9 @@ Short form. Numbers are from the study unless marked as house style.
**Space** **Space**
- One grid, one pair of tight margins (16–32px), used everywhere; large things run to the edges. Text - One grid, one pair of tight margins (16–32px), used everywhere; large things run to the edges. Text
blocks share two or three left edges on the whole page. blocks share two or three left edges on the whole page.
- The gap between sections is clearly larger than any gap inside one: 120–220px on desktop. - Asymmetry inside the grid, never in the frame: the two outer margins are equal, and an off-centre
heading is answered by something at the far side of the grid.
- The gap between sections is clearly larger than any gap inside one: 120–240px on desktop (the study's median is about 240).
- Each section has a different composition from its neighbours; none is a card grid. - Each section has a different composition from its neighbours; none is a card grid.
**Colour** **Colour**
@@ -376,9 +457,28 @@ onto the roles, and take only composition from the draw. The house rules still a
itself requires a banned device (its logo sits in a gradient, its accent is violet), keep the brand itself requires a banned device (its logo sits in a gradient, its accent is violet), keep the brand
asset, say so in the report, and pass `--allow <rule>` to the inspector for that rule only. asset, say so in the report, and pass `--allow <rule>` to the inspector for that rule only.
**Redesign or review of an existing page.** Run `lint.mjs` and `inspect.mjs` on it first and report **Redesign, restyle or review of an existing page or app screen.**
what they find, then critique the screenshots with `references/critique.md`. For a redesign, draw a
direction and proceed from step 2, keeping the page's real content and working behaviour. 1. **Record the before.** Run the project as it is and inspect it into its own folder
(`inspect.mjs <url> --out .taste-skill/before`, with `--app` for an app screen) and lint its
source. Read the code: the framework, the styling method (Tailwind v3 or v4, CSS modules,
styled-components, plain CSS), the components, and what must survive: routes, forms, data,
behaviour, the brand's own assets.
2. **A review stops here.** Critique the before screenshots with `references/critique.md`, list the
findings with the inspector's measurements, and name the three changes that would move the page
most.
3. **Keep the stack, the content and what works.** No framework or styling-library migration; check the
dependency file before adding anything. A restyle keeps the layout and takes type, colour and
components from a dealt direction (`--keep` whatever the brand fixes); a redesign deals a full
direction and rebuilds the sections from its blueprints inside the existing components. Either way
proceed from step 2 of the run with the page's real content.
4. **Order of work, biggest effect for least risk:** type (faces and scale), colour (one ground, one
ink, one accent), the frame (margins, section rhythm, a title on the first screen and a heading on
every section), states (hover, focus, loading, empty, error), then the stock components (icon
cards, pill badges, gradient blobs, card grids) replaced by the dealt blueprints.
5. **Prove it.** Inspect again into `.taste-skill/after`, compare before and after at every width,
click through every link, form and menu that worked before, and report the before and after
measurements side by side.
**A component or a single section, not a page.** Skip the draw unless there is no direction to follow. **A component or a single section, not a page.** Skip the draw unless there is no direction to follow.
Match the surrounding design, apply the house rules and the laws, and still inspect the result. Match the surrounding design, apply the house rules and the laws, and still inspect the result.
@@ -398,17 +498,22 @@ open collections could not be searched.
| File | Read it when | | File | Read it when |
| --- | --- | | --- | --- |
| `references/app-screens.md` | Any dashboard, admin, settings or other app screen: its own run, rules, tokens and checks. |
| `references/copy.md` | Writing the argument and the copy deck (steps 2 and 5). The two-line arithmetic. | | `references/copy.md` | Writing the argument and the copy deck (steps 2 and 5). The two-line arithmetic. |
| `references/type.md` | Setting type: scales, tracking, measure, loading fonts, pairing. | | `references/type.md` | Setting type: scales, tracking, measure, loading fonts, pairing. |
| `references/colour.md` | Applying the palette: roles, proportions, tone steps, dark pages, contrast. | | `references/colour.md` | Applying the palette: roles, proportions, tone steps, dark pages, contrast. |
| `references/layout.md` | Grid, margins, rhythm, section variety, navigation, footer, the phone composition. | | `references/layout.md` | Grid, margins, rhythm, section variety, navigation, footer, the phone composition. |
| `references/imagery.md` | Choosing, finding, crediting, cropping and treating pictures; what to do with none. | | `references/imagery.md` | Choosing, finding, crediting, cropping and treating pictures; what to do with none. |
| `references/motion.md` | Step 9. Budget, tokens, recipes, reduced motion. | | `references/motion.md` | Step 9. Budget, tokens, recipes, reduced motion. |
| `references/scenes.md` | Step 6, when the sheet deals scroll scenes: putting one on a page, filling, fitting, the phone, checking, the catalogue. |
| `references/critique.md` | Step 8. How to look, how to score, what to fix first. | | `references/critique.md` | Step 8. How to look, how to score, what to fix first. |
| `references/tells.md` | The dated registry of generated-page tells and what each is replaced by. | | `references/tells.md` | The dated registry of generated-page tells and what each is replaced by. |
| `references/research.md` | The study: method, numbers, what the best and worst sites do. Cite it, do not guess. | | `references/research.md` | The study: method, numbers, what the best and worst sites do. Cite it, do not guess. |
| `scripts/draw.mjs` | Deals and reprints the direction; `--photos`, `--site <id>` for more references. | | `scripts/draw.mjs` | Deals and reprints the direction; `--photos`, `--site <id>` for more references; `--app` deals an app style instead. |
| `scripts/assets.mjs` | Step 6: searches open collections for real pictures of the subject's world; `--get` downloads with the credit, `--credits` prints them. | | `scripts/assets.mjs` | Step 6: searches open collections for real pictures of the subject's world; `--get` downloads with the credit, `--credits` prints them. |
| `scripts/lint.mjs` · `scripts/inspect.mjs` | The gate. | | `scripts/lint.mjs` · `scripts/inspect.mjs` | The gate. |
| `scripts/scenes.mjs` | The gate for scroll scenes: each scene at 0-100% of its hold, desktop, phone, reduced motion. |
| `assets/base.css` · `assets/base.js` | An optional neutral foundation to build on. | | `assets/base.css` · `assets/base.js` | An optional neutral foundation to build on. |
| `library/` | The data the draw reads: directions, heroes, sections, type systems, palettes, photographs, studied sites, motions. Do not read it whole; use the script. | | `assets/scenes/` | The scroll scenes: the shared stage (`stage.js`, `stage.css`) and, for each scene in the library, its `.js`, `.css` and a working demo page in `demo/`. |
| `assets/app.css` · `assets/charts.js` | For app screens: a neutral shell, panels, tables and controls, and small SVG charts drawn to the app rules. |
| `library/` | The data the draw reads: directions, heroes, sections, type systems, palettes, photographs, studied sites, motions, scroll scenes (`scenes.json`), and the app styles, shells and screen patterns (`app.json`). Do not read it whole; use the script. |
plugins/codex/plugins/taste-skill/skills/taste-skill/assets/app.css
+216
View File
@@ -0,0 +1,216 @@
/* tasteskill / app.css
A neutral foundation for app screens (dashboards, admin, settings, inboxes), set to the defaults
measured in the study of real product screens (references/app-screens.md). Copy it into the project,
replace the token values with the ones on the app sheet (draw.mjs --app), and build on top.
Delete what you do not use. It has no brand of its own: neutral grounds, one quiet line, one accent. */
/* ---------- tokens (replace with the dealt style) ---------- */
:root {
/* names match the app sheet printed by draw.mjs --app */
--ground: #f9fafb; /* the app chrome and page */
--surface: #ffffff; /* panels and the work sheet */
--raised: #f4f5f6; /* a filled inner well, hover rows */
--active: #eeeeee; /* the active nav pill */
--border: #e8e8e8; /* panel edges: about 1.2:1 on white */
--rule: #f1f2f3; /* row rules inside tables */
--control: #d1d5db; /* inputs and outlined buttons: one step stronger */
--text: #111111;
--muted: #5f6368; /* secondary text, labels (4.5:1 or more on its ground) */
--faint: #6b6b6b; /* meta and placeholders: the lightest grey that holds 4.5:1 on white */
--accent: #1f6f5c; /* one hue: data, focus, the selected thing */
--primary: #1d1f20; /* the primary button is near-black unless the style says otherwise */
--primary-ink: #ffffff;
--positive: #247b50; --negative: #c4242a; --warning: #92400e; /* references/app-screens.md §9.5; a green accent is also --positive */
--pill-positive-bg: #dcfae5; --pill-positive-ink: #04250e;
--pill-negative-bg: #ffedea; --pill-negative-ink: #831c1e;
--pill-warning-bg: #fffbeb; --pill-warning-ink: #92400e;
--pill-neutral-bg: #eeeeee; --pill-neutral-ink: #3d3d3d;
--chart-1: var(--accent); --chart-2: #8fb8ad; --chart-3: #b08a2e; --chart-muted: #cfd3d6;
--chart-mark: var(--text); /* a marked period in Charts.diverging: the second tone */
--chart-span: 0.06; /* opacity of a shaded span (a selling window, an outage) */
--grid: var(--rule); /* chart gridlines (charts.js) */
--axis-ink: var(--muted); /* chart tick labels (charts.js) */
--ink: var(--text);
--font: "Inter", system-ui, -apple-system, "Segoe UI", sans-serif;
--fs-title: 24px; --fs-section: 16px; --fs-kpi: 28px; --fs-body: 14px; --fs-small: 12px;
--sidebar-width: 232px;
--pad: 24px; /* canvas padding */
--gap: 16px; /* one gutter, horizontal and vertical */
--card-pad: 20px;
--radius-card: 8px; /* radius is bimodal: tight 4–8 (controls 6) or soft 16–24 (controls full); never 11–12 */
--radius-control: 6px;
--control-height: 32px; /* every control in the title and filter rows */
--row-height: 48px; /* single-line table row */
--nav-row: 32px; /* sidebar item height, on a 34px pitch */
--ease-out: cubic-bezier(0.22, 1, 0.36, 1);
--t-press: 120ms; --t-hover: 150ms; --t-ui: 200ms;
}
/* dark: one true-neutral ground, elevation by lightness; two greys that read apart (not #aaa beside #969696) */
:root[data-theme="dark"] {
--ground: #000000; --surface: #111111; --raised: #222222; --active: #222222;
--border: #1a1a1a; --rule: #161616; --control: #444444;
--text: #ffffff; --muted: #b4b4b4; --faint: #949494;
--primary: #ffffff; --primary-ink: #000000;
--positive: #3fc07a; --negative: #e5566f; --warning: #e5a93b; /* a green or yellow-green accent is also --positive */
--pill-positive-bg: #172a1d; --pill-positive-ink: #3fc07a;
--pill-negative-bg: #2c1a20; --pill-negative-ink: #e5566f;
--pill-warning-bg: #2b2414; --pill-warning-ink: #e5a93b;
--pill-neutral-bg: #222222; --pill-neutral-ink: #ffffff;
--chart-muted: #4a4a4a; --grid: #2b2b2b;
--chart-span: 0.12;
}
/* ---------- reset ---------- */
*, *::before, *::after { box-sizing: border-box; }
html { -webkit-text-size-adjust: 100%; text-size-adjust: 100%; }
body { margin: 0; background: var(--ground); color: var(--text); font: var(--fs-body)/20px var(--font); -webkit-font-smoothing: antialiased; }
h1, h2, h3, h4, p, figure, ul, ol, dl, dd { margin: 0; }
ul[class], ol[class] { padding: 0; list-style: none; }
img, svg, video, canvas { display: block; max-width: 100%; }
button, input, select, textarea { font: inherit; color: inherit; }
a { color: inherit; text-decoration: none; }
:focus-visible { outline: 2px solid var(--accent); outline-offset: 2px; border-radius: 4px; }
.num, table, .kpi-value { font-variant-numeric: tabular-nums; }
/* ---------- shell: sidebar + canvas ---------- */
.app { display: grid; grid-template-columns: var(--sidebar-width) minmax(0, 1fr); min-height: 100svh; }
.sidebar { position: sticky; top: 0; height: 100svh; display: flex; flex-direction: column; gap: 2px; padding: 16px 12px; overflow: auto; }
.sidebar .group-label { margin: 20px 8px 6px; font-size: var(--fs-small); color: var(--faint); }
.nav-item { display: flex; align-items: center; gap: 10px; height: var(--nav-row); padding: 0 8px; border-radius: 8px; color: var(--muted); transition: background-color var(--t-hover) ease, color var(--t-hover) ease; }
.nav-item svg { width: 16px; height: 16px; flex: none; stroke-width: 1.5; }
.nav-item:hover { background: var(--raised); color: var(--text); }
.nav-item[aria-current="page"] { background: var(--active); color: var(--text); }
.sidebar .bottom { margin-top: auto; }
.canvas { min-width: 0; padding: var(--pad); }
/* ---------- title block and filters ---------- */
.title-row { display: flex; align-items: flex-end; justify-content: space-between; gap: 16px; margin-bottom: 20px; }
.title-row h1 { font-size: var(--fs-title); line-height: 1.2; font-weight: 600; letter-spacing: -0.01em; }
.title-row .sub { margin-top: 4px; color: var(--muted); }
.filters { display: flex; align-items: center; gap: 8px; margin-bottom: var(--gap); flex-wrap: wrap; }
.filters .spacer { flex: 1; }
.stamp { color: var(--faint); font-size: var(--fs-small); }
/* ---------- panels and grid ---------- */
.grid { display: grid; grid-template-columns: repeat(12, minmax(0, 1fr)); gap: var(--gap); }
.panel { background: var(--surface); border: 1px solid var(--border); border-radius: var(--radius-card); padding: var(--card-pad); min-width: 0; }
.panel > header { display: flex; align-items: center; justify-content: space-between; gap: 12px; margin-bottom: 16px; }
.panel h2 { font-size: var(--fs-section); line-height: 1.3; font-weight: 600; }
.panel .meta { color: var(--faint); font-size: var(--fs-small); }
/* paired cards in one row: a card stretches to its neighbour only when it has content to fill. Otherwise it keeps
its own height (add .top to the row), and only an action or a total may be pinned to a stretched card's bottom */
.grid.top { align-items: start; }
/* a chart's heading row: its title (and legend or period) with a fixed 8px to the svg */
.chart-head { display: flex; align-items: baseline; justify-content: space-between; flex-wrap: wrap; gap: 4px 12px; margin-bottom: 8px; }
.chart-head h3 { font-size: var(--fs-body); line-height: 20px; font-weight: 500; }
.chart { position: relative; min-width: 0; }
/* a link at a card's foot or header ("Show all 7", "Sell-out history"): ink, a 12px chevron, an underline on hover,
and no inline padding, so its text sits on the card's content edge */
.card-link { display: inline-flex; align-items: center; gap: 2px; padding: 0; border: 0; background: none; color: var(--text); font-weight: 500; cursor: pointer; text-underline-offset: 3px; }
.card-link::after { content: ""; width: 12px; height: 12px; flex: none; background: currentColor; -webkit-mask: var(--chevron) center / 12px no-repeat; mask: var(--chevron) center / 12px no-repeat; }
.card-link:hover { text-decoration: underline; }
:root { --chevron: url("data:image/svg+xml,%3Csvg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 12 12'%3E%3Cpath d='M4.5 2.5 8 6l-3.5 3.5' fill='none' stroke='black' stroke-width='1.5' stroke-linecap='round' stroke-linejoin='round'/%3E%3C/svg%3E"); }
/* list rows: a rule between rows and none above the first. A rule on a rounded box curls up at both ends, so a row
that carries a rule has square corners */
.rows { display: grid; }
.row { display: flex; align-items: center; gap: 12px; min-height: 44px; padding: 10px 0; }
.row + .row { border-top: 1px solid var(--rule); border-radius: 0; }
/* KPIs as one divided strip: a label above a number, no icons, no tiles */
.kpis { display: grid; grid-auto-flow: column; grid-auto-columns: minmax(0, 1fr); background: var(--surface); border: 1px solid var(--border); border-radius: var(--radius-card); }
.kpi { padding: 16px var(--card-pad); }
.kpi + .kpi { border-left: 1px solid var(--border); }
.kpi-label { color: var(--muted); }
.kpi-value { margin-top: 6px; font-size: var(--fs-kpi); line-height: 1.15; font-weight: 500; letter-spacing: -0.01em; }
.kpi-value small { font-size: 0.55em; color: var(--muted); font-weight: 400; margin-left: 2px; }
.delta { margin-top: 4px; font-size: var(--fs-small); color: var(--muted); }
.delta .up { color: var(--positive); } .delta .down { color: var(--negative); }
/* KPIs as the chart's tabs: the selected one carries a 2px rule and an ink label; the others keep a grey label and
their value in ink at a lighter weight (a grey value reads as disabled). When the tabs are the per-entity
breakdown the brief asks for (takings by shop), add .entities: nothing changes but the rule */
.kpis[role="tablist"] .kpi { position: relative; cursor: pointer; }
.kpis[role="tablist"] .kpi[aria-selected="true"]::after { content: ""; position: absolute; left: 0; right: 0; bottom: -1px; height: 2px; background: var(--text); }
.kpis[role="tablist"]:not(.entities) .kpi[aria-selected="true"] .kpi-label { color: var(--text); }
.kpis[role="tablist"]:not(.entities) .kpi[aria-selected="false"] .kpi-value { color: var(--text); font-weight: 400; }
/* ---------- tables ---------- */
.table-wrap { overflow-x: auto; }
table { width: 100%; border-collapse: collapse; }
th { height: 36px; padding: 0 12px; text-align: left; font-weight: 400; font-size: var(--fs-small); color: var(--muted); border-bottom: 1px solid var(--border); white-space: nowrap; }
/* cells share one baseline, so a figure never sits 2px below the name beside it; the row height comes from padding */
td { padding: calc((var(--row-height) - 20px) / 2) 12px; border-bottom: 1px solid var(--rule); vertical-align: baseline; }
tbody tr:last-child td { border-bottom: 0; }
/* no hover that changes the fill; a row that drives a detail pane takes the nav pill's fill when selected */
tbody tr[aria-selected="true"] td { background: var(--active); }
th.n, td.n { text-align: right; }
td .sub { display: block; font-size: var(--fs-small); color: var(--muted); }
.truncate { max-width: 28ch; overflow: hidden; text-overflow: ellipsis; white-space: nowrap; }
/* status pill: a pale tint with dark ink of the same hue, one per row */
.pill { display: inline-flex; align-items: center; gap: 6px; height: 22px; padding: 0 8px; border-radius: 999px; font-size: var(--fs-small); font-weight: 500; background: var(--pill-neutral-bg); color: var(--pill-neutral-ink); white-space: nowrap; }
.pill.pos { background: var(--pill-positive-bg); color: var(--pill-positive-ink); }
.pill.neg { background: var(--pill-negative-bg); color: var(--pill-negative-ink); }
.pill.warn { background: var(--pill-warning-bg); color: var(--pill-warning-ink); }
/* ---------- controls ---------- */
.btn { display: inline-flex; align-items: center; justify-content: center; gap: 8px; height: var(--control-height); padding: 0 12px; border-radius: var(--radius-control); border: 1px solid var(--control); background: var(--surface); font-weight: 500; cursor: pointer; transition: background-color var(--t-hover) ease, transform var(--t-press) var(--ease-out); }
.btn:hover { background: var(--raised); }
.btn:active { transform: translateY(1px); }
.btn.primary { background: var(--primary); color: var(--primary-ink); border-color: transparent; }
.btn.ghost { border-color: transparent; background: transparent; }
.field { display: grid; gap: 8px; }
.field label { font-weight: 500; }
.field .hint { color: var(--muted); font-size: var(--fs-small); }
.input, select.input { height: 38px; padding: 0 12px; border: 1px solid var(--control); border-radius: var(--radius-control); background: var(--surface); }
.input::placeholder { color: var(--faint); }
.tabs { display: flex; gap: 24px; border-bottom: 1px solid var(--border); margin-bottom: var(--gap); }
.tabs a { position: relative; padding: 10px 0; color: var(--muted); transition: color var(--t-hover) ease; }
.tabs a[aria-selected="true"] { color: var(--text); }
.tabs a[aria-selected="true"]::after { content: ""; position: absolute; left: 0; right: 0; bottom: -1px; height: 2px; background: var(--text); }
/* as wide as its options; full width only on a narrow phone */
.segmented { display: inline-flex; width: max-content; max-width: 100%; padding: 2px; border-radius: 8px; background: var(--raised); }
.segmented button { height: 28px; padding: 0 10px; border: 0; border-radius: 6px; background: transparent; color: var(--muted); cursor: pointer; }
.segmented button[aria-pressed="true"] { background: var(--surface); color: var(--text); }
.switch { appearance: none; width: 32px; height: 20px; border-radius: 999px; background: var(--control); position: relative; cursor: pointer; transition: background-color var(--t-ui) ease; }
.switch::after { content: ""; position: absolute; top: 2px; left: 2px; width: 16px; height: 16px; border-radius: 50%; background: #fff; transition: transform var(--t-ui) var(--ease-out); }
.switch:checked { background: var(--text); } .switch:checked::after { transform: translateX(12px); }
/* empty and loading states keep the frame; a loading value is a flat grey bar at its real size, with no shimmer */
.empty { display: grid; place-items: center; min-height: 96px; padding: 16px; border: 1px dashed var(--control); border-radius: var(--radius-control); color: var(--muted); text-align: center; }
.skeleton { background: var(--raised); border-radius: 4px; }
/* ---------- phone: the navigation folds away and the canvas takes the width ---------- */
.menu-toggle { display: none; }
@media (max-width: 860px) {
.app { grid-template-columns: minmax(0, 1fr); }
/* the menu opens as a full-screen sheet */
.sidebar { position: fixed; inset: 0; width: 100%; height: 100%; z-index: 20; background: var(--surface); transform: translateX(-100%); transition: transform var(--t-ui) var(--ease-out); }
.sidebar.open { transform: none; }
.menu-toggle { display: inline-flex; }
.canvas { padding: 16px; }
.grid > * { grid-column: 1 / -1 !important; }
.kpis { grid-auto-flow: row; grid-template-columns: repeat(2, minmax(0, 1fr)); }
.kpi + .kpi { border-left: 0; }
.kpi:nth-child(n + 3) { border-top: 1px solid var(--border); }
.kpi:nth-child(2n) { border-left: 1px solid var(--border); }
/* an odd count leaves no half-empty row: the last cell takes the full width */
.kpi:last-child:nth-child(odd) { grid-column: 1 / -1; }
/* KPI tabs in a 2-up grid: the selected cell takes a fill, never an underline floating mid-grid */
.kpis[role="tablist"] .kpi[aria-selected="true"] { background: var(--active); }
.kpis[role="tablist"] .kpi[aria-selected="true"]::after { content: none; }
.title-row { flex-wrap: wrap; align-items: flex-start; }
}
@media (max-width: 480px) {
.segmented { display: flex; width: 100%; }
.segmented button { flex: 1; }
}
@media (prefers-reduced-motion: reduce) { *, *::before, *::after { transition-duration: 0.01ms !important; animation: none !important; } }
/* an empty message spans the block it stands in, never one squeezed column */
.rows .empty, .grid > .empty, li > .empty { grid-column: 1 / -1; width: 100%; }
Loaded 100 of 126 files, more files were not shown because too many files have changed in this diff. Show more