Back to Details

f1-test-drive

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

F1 Test Drive

F1测试流程

Run comprehensive F1 test drives that validate the full pipeline:
  • Issue-tracker behavior
  • EdgeWorker execution flow
  • Activity rendering/output quality
运行全面的F1测试流程，验证完整的流水线：
  • 问题追踪器行为
  • EdgeWorker执行流程
  • 活动渲染/输出质量

Mission

任务目标

Execute test drives that verify:
  1. Issue-tracker correctness
  2. EdgeWorker worktree/session behavior
  3. Activity output visibility and formatting
执行测试流程以验证：
  1. 问题追踪器正确性
  2. EdgeWorker工作树/会话行为
  3. 活动输出的可见性与格式

Test Drive Protocol

测试流程协议

Phase 1: Setup

第一阶段：环境搭建

  1. Create a fresh test repository (if needed):
    bash
    cd apps/f1
./f1 init-test-repo --path /tmp/f1-test-drive-<timestamp>
  2. Start F1 server:
    bash
    CYRUS_PORT=3600 CYRUS_REPO_PATH=/tmp/f1-test-drive-<timestamp> bun run apps/f1/server.ts &
  3. Verify server health:
    bash
    CYRUS_PORT=3600 ./f1 ping
CYRUS_PORT=3600 ./f1 status
  1. 创建新的测试仓库（如有需要）：
    bash
    cd apps/f1
./f1 init-test-repo --path /tmp/f1-test-drive-<timestamp>
  2. 启动F1服务器：
    bash
    CYRUS_PORT=3600 CYRUS_REPO_PATH=/tmp/f1-test-drive-<timestamp> bun run apps/f1/server.ts &
  3. 验证服务器健康状态：
    bash
    CYRUS_PORT=3600 ./f1 ping
CYRUS_PORT=3600 ./f1 status

Phase 2: Issue-Tracker Verification

第二阶段：问题追踪器验证

  1. Create test issue:
    bash
    CYRUS_PORT=3600 ./f1 create-issue \
  --title "<issue title>" \
  --description "<issue description>"
  2. Verify issue ID and issue creation response.
  1. 创建测试问题：
    bash
    CYRUS_PORT=3600 ./f1 create-issue \
  --title "<issue title>" \
  --description "<issue description>"
  2. 验证问题ID和问题创建响应。

Phase 3: EdgeWorker Verification

第三阶段：EdgeWorker验证

  1. Start agent session:
    bash
    CYRUS_PORT=3600 ./f1 start-session --issue-id <issue-id>
  2. Monitor activities:
    bash
    CYRUS_PORT=3600 ./f1 view-session --session-id <session-id>
  3. Verify:
    • session started
    • activities appear
    • agent is processing issue
  1. 启动agent会话：
    bash
    CYRUS_PORT=3600 ./f1 start-session --issue-id <issue-id>
  2. 监控活动：
    bash
    CYRUS_PORT=3600 ./f1 view-session --session-id <session-id>
  3. 验证以下内容：
    • 会话已启动
    • 活动已生成
    • agent正在处理问题

Phase 3.5: Slack Chat Session Verification (optional)

第三阶段补充：Slack聊天会话验证（可选）

Use when validating the Slack → ChatSessionHandler → ClaudeRunner path. F1 exposes a test-only endpoint 
/cli/dispatch-chat
that injects a synthetic 
app_mention
event without going through Slack signature verification (
SlackChatAdapter
no-ops Slack API calls when 
slackBotToken
is undefined).
  1. Dispatch a synthetic chat event:
    bash
    CYRUS_PORT=3600 ./f1 start-chat-session \
  --channel C_TEST_CHAN \
  --user U_TEST_USER \
  --text "hello"
    The response contains a 
    threadKey
    of the form 
    <channel>:<ts>
    . Reuse the same 
    --thread-ts
    to address the same chat thread on subsequent dispatches.
  2. Verify shared auto-memory wiring:
    • The chat workspace exists at 
      <cyrusHome>/slack-workspaces/<sanitized-threadKey>/
      .
    • The shared auto-memory directory exists (or is lazily creatable) at 
      <cyrusHome>/slack-memory/
      .
    • The 
      claude_query_options
      event emitted by 
      ClaudeRunner
      carries 
      cqo.settingsAutoMemoryDirectory=<cyrusHome>/slack-memory
      .
  3. Verify per-thread workspace isolation alongside shared memory:
    • Dispatch a second event in a different channel/thread.
    • Confirm a separate 
      slack-workspaces/<other-thread-key>/
      directory exists (workspaces remain isolated).
    • Confirm both dispatches' telemetry resolve to the same 
      slack-memory
      path (memory is shared).
用于验证Slack → ChatSessionHandler → ClaudeRunner流程。F1提供了一个仅用于测试的端点
/cli/dispatch-chat
，可注入模拟的
app_mention
事件，无需经过Slack签名验证（当
slackBotToken
未定义时，
SlackChatAdapter
会让Slack API调用无操作）。
  1. 分发模拟聊天事件：
    bash
    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
      路径（内存共享）。

Phase 4: Renderer Verification

第四阶段：渲染器验证

  1. Validate activity payload quality:
    • expected types (for example 
      thought
      , 
      action
      , 
      response
      )
    • timestamps present
    • content well-formed and readable
  2. Validate pagination behavior:
    bash
    CYRUS_PORT=3600 ./f1 view-session --session-id <session-id> --limit 10 --offset 0
  1. 验证活动负载质量：
    • 符合预期的类型（例如
      thought
      、
      action
      、
      response
      ）
    • 包含时间戳
    • 内容格式规范且可读
  2. 验证分页行为：
    bash
    CYRUS_PORT=3600 ./f1 view-session --session-id <session-id> --limit 10 --offset 0

Phase 5: Cleanup

第五阶段：环境清理

  1. Stop active session:
    bash
    CYRUS_PORT=3600 ./f1 stop-session --session-id <session-id>
  2. Stop background server process.
  1. 停止活跃会话：
    bash
    CYRUS_PORT=3600 ./f1 stop-session --session-id <session-id>
  2. 停止后台服务器进程。

Reporting Format

报告格式

Write report under 
apps/f1/test-drives/
:
markdown
undefined
在
apps/f1/test-drives/
目录下撰写报告：
markdown
undefined

Test Drive #NNN: [Goal Description]

Test Drive #NNN: [Goal Description]

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

Verification Results

Verification Results

Issue-Tracker

Issue-Tracker

  • Issue created
  • Issue ID returned
  • Issue metadata accessible
  • Issue created
  • Issue ID returned
  • Issue metadata accessible

EdgeWorker

EdgeWorker

  • Session started
  • Worktree created (if applicable)
  • Activities tracked
  • Agent processed issue
  • Session started
  • Worktree created (if applicable)
  • Activities tracked
  • Agent processed issue

Renderer

Renderer

  • Activity format correct
  • Pagination works
  • Search works
  • Activity format correct
  • Pagination works
  • Search works

Session Log

Session Log

[commands + key outputs + pass/fail]
[commands + key outputs + pass/fail]

Final Retrospective

Final Retrospective

[what worked, issues, recommendations]
undefined
[what worked, issues, recommendations]
undefined

Pass/Fail Criteria

通过/失败标准

Pass when:
  1. Server starts
  2. Issue created successfully
  3. Session starts and activities appear
  4. Activity payloads are coherent
  5. Session stops cleanly
  6. No unhandled errors
Fail when:
  • server startup fails
  • issue creation fails
  • session does not start
  • no activities after reasonable wait
  • malformed activity data
  • unhandled exceptions
满足以下条件则通过：
  1. 服务器成功启动
  2. 问题创建成功
  3. 会话启动且活动生成
  4. 活动负载内容连贯
  5. 会话正常停止
  6. 无未处理错误
出现以下情况则失败：
  • 服务器启动失败
  • 问题创建失败
  • 会话无法启动
  • 等待合理时间后仍无活动生成
  • 活动数据格式错误
  • 出现未处理异常

Important Notes

重要注意事项

  • Prefer fixed port 
    3600
    unless already in use.
  • Use fresh test repos per drive.
  • Preserve failed state when debugging.
  • For major runner/harness changes, run at least one F1 end-to-end validation before merge.
  • 优先使用固定端口
    3600
    ，除非该端口已被占用。
  • 每次测试流程使用新的测试仓库。
  • 调试时保留失败状态。
  • 对于runner/harness的重大变更，合并前至少运行一次F1端到端验证。

Multi-Harness Note

多适配层说明

This skill is intentionally harness-agnostic:
  • Claude subagents can call this skill.
  • Codex/OpenCode workflows can reference the same skill content.
  • Harness-specific adapters should be thin wrappers around this canonical skill.
本技能设计为适配层无关：
  • Claude子agent可调用本技能。
  • Codex/OpenCode工作流可引用相同的技能内容。
  • 适配层专属的适配器应作为本标准技能的轻量包装。