mcpField
F
f1-test-drive

f1-test-drive

github.com/cyrusagents测试与质量879810 次安装今天更新
代码仓库

关于 f1-test-drive

此测试技能规定 Cyrus 运行时及 F1 测试框架变更的验证时机与方法。它将变更行为对应到适用场景，并明确不适用时不运行 F1 或创建报告。

主要功能

  1. 01根据差异判断 F1 是否适用
  2. 02为变更行为选择测试场景
  3. 03设置测试仓库和 F1 服务
  4. 04验证问题、会话及活动流程
  5. 05仅为适用的测试运行编写报告
  6. 06对非 F1 变更执行针对性检查

适用场景

  1. 01验证运行时路由或会话变更
  2. 02测试 F1 命令或活动渲染变更
  3. 03评估发布内容的测试覆盖
  4. 04检查文档或工具变更且不生成 F1 报告

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/cyrusagents/cyrus --skill f1-test-drive

安装后在 Claude Code 中输入/f1-test-drive确认已加载。

详细介绍

F1 测试演练

适用性（设置前必须确认）

这是权威的 F1 适用性政策。开始 F1、选择测试夹具或创建报告前，请检查相对于 PR 基础版本的实际差异，并确定需要验证的行为。任务规模、问题标签、文件名以及笼统的验证／发布请求，都不足以成为运行 F1 的理由。

  • 必须运行： 由 F1 覆盖的产品／运行时变更（问题跟踪、身份验证、路由、运行器／会话生命周期、活动渲染），以及对 F1 测试框架本身的功能性变更。选择带有断言、能够覆盖变更行为的场景；通用健康检查或无关的测试夹具无法证明正确性。
  • 不适用： 文档、Agent 指令、CI／发布工具、安装器／构建／打包元数据，或其他不涉及相关产品工作流行为的变更。请改用适当的文档、脚本、单元、集成、构建、包检查或隔离安装冒烟测试。不要运行 F1，也不要创建、附加或提交 F1 测试演练报告。只需在 PR 中简要说明 F1 为何不适用，以及通过了哪些检查。
  • 混合变更： 仅对相关功能部分运行 F1；其他部分使用针对性检查进行验证。文档、基础设施或元数据路径，不能成为不验证实际运行时行为变更的理由（包括依赖项、生成的提示词或安装后的默认设置）。
  • 实际发布： 应根据上一版本评估完整的发布内容，而不只是版本号更新 PR。包含运行时内容的发布仍须进行相关 F1 验证。没有 F1 覆盖行为变更的发布，应按 apps/cli/RELEASING.md 所述进行非 F1 发布验证。编辑发布工具本身，并不等于准备或发布功能版本。

如果 F1 不适用，请在设置和报告前停止此流程。如果适用但受阻，请如实报告缺失的覆盖范围和阻碍；不要将其重新标记为不适用，也不要用无关且通过的演练替代。保留历史报告。

实际变更验证方式
PR #1502 的制品工作流和隔离安装器工具，不涉及单独的 Agent 身份功能进行工作流／脚本测试、包完整性检查、隔离安装和 CLI 冒烟测试；不使用无关的身份 F1 测试夹具或报告。
README 措辞或仅涉及指令的政策（例如 CYPACK-1537）检查一致性、链接和政策示例；不提交 F1 报告。发布验证器的编辑应按比例进行验证；对影响重大的证据验收失败，仍须保留测试。
运行时路由修复及文档变更运行断言路由变更的 F1 场景；其余部分进行文档检查。
EdgeWorker 身份验证、路由或会话生命周期根据变更运行相关 F1 场景，断言身份隔离、所选存储库或会话延续／终止行为。
F1 RPC 命令、测试夹具执行或活动渲染器行为端到端测试变更涉及的测试框架路径，并运行其单元／集成测试。仅编辑 F1 文档时，仍进行文档检查。
仅更改版本号、但发布内容包含尚未发布的会话修复的发布 PR评估上一版本以来的变更；运行相关的会话 F1 验证。
仅发布基础设施／文档变更，且不涉及相关工作流行为将发布内容评估和针对性检查记录为非 F1 发布验证；不编造 F1 报告。

任务（适用时）

通过相关的问题跟踪器、EdgeWorker 和活动输出路径，验证变更后的工作流。开始设置前，明确场景、预期行为和断言。以下阶段可作为构建模块；只包含该场景所需的路径，以及设置和清理步骤。

测试演练流程

阶段 1：设置

  1. 创建一个全新的测试存储库（如有需要）：

    cd apps/f1
./f1 init-test-repo --path /tmp/f1-test-drive-<timestamp>

  2. 启动 F1 服务：

    CYRUS_PORT=3600 CYRUS_REPO_PATH=/tmp/f1-test-drive-<timestamp> bun run apps/f1/server.ts &

  3. 检查服务健康状态：

    CYRUS_PORT=3600 ./f1 ping
CYRUS_PORT=3600 ./f1 status
阶段 2：问题跟踪器验证

  1. 创建测试问题：

    CYRUS_PORT=3600 ./f1 create-issue \
  --title "<issue title>" \
  --description "<issue description>"

  2. 验证问题 ID 和问题创建响应。

阶段 3：EdgeWorker 验证

  1. 启动 Agent 会话：

    CYRUS_PORT=3600 ./f1 start-session --issue-id <issue-id>

  2. 监控活动：

    CYRUS_PORT=3600 ./f1 view-session --session-id <session-id>

  3. 验证：

    • 会话已启动
    • 活动已出现
    • Agent 正在处理问题
阶段 3.5：Slack 聊天会话验证（可选）

在验证 Slack → ChatSessionHandler → ClaudeRunner 路径时使用。F1 提供了仅用于测试的端点 /cli/dispatch-chat，可注入合成的 app_mention 事件，而无需经过 Slack 签名验证（当 slackBotToken 未定义时，SlackChatAdapter 不会调用 Slack API）。

  1. 分发合成聊天事件：

    CYRUS_PORT=3600 ./f1 start-chat-session \
  --channel C_TEST_CHAN \
  --user U_TEST_USER \
  --text "hello"

    响应中包含格式为 <channel>:<ts> 的 threadKey。后续分发时，重复使用相同的 --thread-ts，以指向同一个聊天线程。

  2. 验证共享自动记忆接线：

    • 聊天工作区位于 <cyrusHome>/slack-workspaces/<sanitized-threadKey>/。
    • 共享自动记忆目录位于（或可延迟创建于）<cyrusHome>/slack-memory/。
    • ClaudeRunner 发出的 claude_query_options 事件包含 cqo.settingsAutoMemoryDirectory=<cyrusHome>/slack-memory。

  3. 验证各线程工作区彼此隔离，同时共享记忆：

    • 在不同的频道/线程中分发第二个事件。
    • 确认存在单独的 slack-workspaces/<other-thread-key>/ 目录（工作区保持隔离）。
    • 确认两次分发的遥测都指向同一个 slack-memory 路径（记忆是共享的）。
阶段 4：渲染器验证

  1. 验证活动载荷质量：

    • 类型符合预期（例如 thought、action、response）
    • 包含时间戳
    • 内容格式正确且可读

  2. 验证分页行为：

    CYRUS_PORT=3600 ./f1 view-session --session-id <session-id> --limit 10 --offset 0
阶段 5：清理

  1. 停止活动会话：

    CYRUS_PORT=3600 ./f1 stop-session --session-id <session-id>

  2. 停止后台服务进程。

报告格式

仅在完成适用的 F1 测试后，才在 apps/f1/test-drives/ 下编写报告。 记录测试的提交、行为变更、命令、断言、结果和限制。 根据相关场景调整此模板；省略不相关的检查项。切勿创建占位报告或标记为“不适用”的 F1 报告：

# Test Drive #NNN: [Goal Description]

**Date**: YYYY-MM-DD
**Goal**: [One sentence]
**Test Repo**: [Path]

## Verification Results

### Issue-Tracker
- [ ] Issue created
- [ ] Issue ID returned
- [ ] Issue metadata accessible

### EdgeWorker
- [ ] Session started
- [ ] Worktree created (if applicable)
- [ ] Activities tracked
- [ ] Agent processed issue

### Renderer
- [ ] Activity format correct
- [ ] Pagination works
- [ ] Search works

## Session Log
[commands + key outputs + pass/fail]

## Final Retrospective
[what worked, issues, recommendations]

通过/失败标准

只有在行为变更断言通过，且适用的工作流检查也通过时，才算通过：

  1. 服务成功启动
  2. 成功创建问题
  3. 会话启动且活动出现
  4. 活动载荷内容连贯
  5. 会话正常停止
  6. 没有未处理的错误

以下情况判定为失败：

  • 服务启动失败
  • 问题创建失败
  • 会话未启动
  • 等待合理时长后仍无活动
  • 活动数据格式错误
  • 出现未处理的异常

重要说明

  • 除非端口已被占用，否则优先使用固定端口 3600。
  • 每次测试使用全新的测试仓库。
  • 调试时保留失败状态。
  • 对于功能性 Runner/Harness 变更，应在合并前按照上述适用性政策，对受影响路径进行端到端验证。

多 Harness 说明

此技能刻意与 Harness 无关：

  • Claude 子 Agent 可以调用此技能。
  • Codex/OpenCode 工作流可以引用相同的技能内容。
  • 特定 Harness 的适配器应当只是此规范技能的轻量封装。

评论

支持 Markdown