rust-worker

name	rust-worker
description	General-purpose Rust implementation worker for Switchboard codebase

Rust Worker

NOTE: Startup and cleanup are handled by worker-base. This skill defines the WORK PROCEDURE.

When to Use This Skill

Any feature that involves writing Rust code in the Switchboard workspace: new crates, new modules, wiring existing code, fixing bugs, adding tests, creating documentation.

Required Skills

None.

Work Procedure

1. Read the feature description carefully. Understand preconditions, expected behavior, and verification steps.

2. Investigate existing code relevant to this feature. Read the files you'll modify. Understand patterns, imports, error handling conventions. Check .factory/library/architecture.md for system-level context.

3. Write tests first (TDD). For each behavior in expectedBehavior:

   • Write a failing test in a #[cfg(test)] module in the same file (following existing convention)
   • Use tempfile::TempDir for any file/DB operations
   • Run cargo test -p <crate> -- <test_name> to confirm the test fails (red)

4. Implement the feature to make tests pass (green):

   • Follow existing code style: workspace deps, thiserror errors, tracing logging, ULID IDs
   • Use pub(crate) for internal APIs, pub only for cross-crate interfaces
   • Add doc comments on public types and functions
   • Keep modules focused — one concern per file

5. Run full validation:

   • cargo test --workspace --exclude app — all tests pass
   • cargo clippy --workspace --exclude app --all-targets -- -D warnings — zero warnings
   • cargo fmt --check — formatted

6. Manual verification (for features with observable behavior):

   • Build the binary: cargo build -p sb-cli
   • Test relevant CLI commands in a temp workspace
   • For MCP features: pipe JSON-RPC messages to stdin, verify responses
   • Record each manual check as an interactiveChecks entry

7. Commit atomically. Each logical unit of work gets its own commit. Use conventional commit messages: feat(crate): description, fix(crate): description, test(crate): description.

Example Handoff

{
  "salientSummary": "Implemented the mark_done evidence guard in sb-mcp. Added regex scanner for TODO/FIXME/XXX/mock_/stub_ patterns in git diff of changed files. Ran cargo test -p sb-mcp (12 passing including 4 new evidence guard tests). Manual verification: piped mark_done JSON-RPC with a planted TODO in a test file, confirmed rejection with file:line locations in the error response.",
  "whatWasImplemented": "mark_done MCP tool handler with configurable regex evidence guard. Scans git diff of changed files in the commit referenced by commit_sha evidence. Returns error with file:line locations if markers found. Supports require_evidence=false override (logged to event store). Added 4 unit tests covering: happy path, TODO rejection, FIXME rejection, and override path.",
  "whatWasLeftUndone": "",
  "verification": {
    "commandsRun": [
      { "command": "cargo test -p sb-mcp", "exitCode": 0, "observation": "12 tests passed, 0 failed" },
      { "command": "cargo clippy --workspace --exclude app --all-targets -- -D warnings", "exitCode": 0, "observation": "No warnings" },
      { "command": "cargo fmt --check", "exitCode": 0, "observation": "Formatted" }
    ],
    "interactiveChecks": [
      { "action": "Piped mark_done JSON-RPC with task containing TODO in changed file", "observed": "Received error response: todo_markers_present with paths [\"src/auth.rs:42\"]" },
      { "action": "Piped mark_done with require_evidence=false", "observed": "Received success response, event logged with override flag" }
    ]
  },
  "tests": {
    "added": [
      {
        "file": "crates/sb-mcp/src/tools/mark_done.rs",
        "cases": [
          { "name": "test_mark_done_happy_path", "verifies": "Task with clean commit completes successfully" },
          { "name": "test_mark_done_rejects_todo", "verifies": "TODO marker in changed file causes rejection" },
          { "name": "test_mark_done_rejects_fixme", "verifies": "FIXME marker in changed file causes rejection" },
          { "name": "test_mark_done_override", "verifies": "require_evidence=false bypasses check with audit log" }
        ]
      }
    ]
  },
  "discoveredIssues": []
}

When to Return to Orchestrator

• Feature depends on a crate that doesn't exist yet (e.g., sb-memory not created)
• External path dependency (agit-core, osp-vault) has API changes or doesn't compile
• Feature requires adding a new workspace member to Cargo.toml (orchestrator should approve)
• Requirements conflict with existing code patterns or invariants
• Build fails due to issues outside this feature's scope