feat(commands): /loop /schedule /team-onboarding + expand /logout (#43 #58 #60 #63)

[yaohaowei0914]

Summary

Ships the scheduling/automation (#58, #60) and onboarding/logout (#43, #63) groups as one change because they share infrastructure.

• services/scheduler — JSON-backed recurring-task store (interval parsing, cross-process lockfile, atomic writes). Shared by /loop and /schedule.
• services/onboarding — persistent first-run state consumed by both the expanded /logout and /team-onboarding.

What's in it

/loop — #58

commands/loop_cmd.rs

• /loop <interval> <payload> creates a recurring task; plain-prompt payloads return CommandResult::Query so they run once immediately (matching the Bun reference). Slash-command payloads are registered but not auto-dispatched (avoids re-entering /loop).
• Subcommands: list, remove, trigger, pause, resume, help.
• Intervals: 30s / 5m / 1h / 2d / */10 * * * * (full cron is future work; only the minute stride is honored today, with a clear error for anything richer).

/schedule — #60

commands/schedule.rs

• Raw management surface over the same store: add, list, show, remove, pause, resume, trigger, due.
• Local cron is the first milestone. Help output and /schedule remote … both explicitly flag the remote-triggers capability as separate and not yet implemented, keeping the two lines un-blurred per the issue's guidance.

/logout — #43

commands/logout.rs

• Expanded from "clear credentials" to a structured LogoutReport:
  • Keychain + credentials.json cleared (via existing auth::oauth_logout).
  • Onboarding state reset in place (update + reset_for_logout) so display_name — a preference, not an identity artifact — survives.
  • ANTHROPIC_API_KEY / ANTHROPIC_AUTH_TOKEN env overrides detected and surfaced as follow-up.
  • Managed (policy) settings path reported but never touched — those are admin-owned.
• Idempotent: returns a friendly no-op report when nothing is present.

/team-onboarding — #63

commands/team_onboarding.rs

• Generates a Markdown teammate guide grounded in real local state, not a template: CLAUDE.md, README.md, git origin/branch, skills registry, teams on disk, scheduled tasks, onboarding status.
• /team-onboarding save [path] writes to a file (default ONBOARDING_TEAM.md).
• Risk areas are keyed off project state (e.g. missing CLAUDE.md, incomplete auth onboarding, first-run flag).

Tests

• 21 scheduler (interval + task + store) + 4 onboarding unit tests
• 9 /loop + 10 /schedule + 9 /logout + 14 /team-onboarding handler tests
• Command-registry assertions for new names/aliases (loop, schedule + cron, team-onboarding + teamonboarding)
• Full non-UI suite passes serially (1253/1253). The 12 failures seen under parallel runs are pre-existing concurrency flakes in unrelated modules (teams::, commands::branch, tools::worktree, etc.) — verified by running them in isolation on both base and HEAD.

Test plan

• cargo build -p claude-code-rs — clean (only 2 pre-existing warnings in web/handlers.rs)
• cargo test -p claude-code-rs --bin claude-code-rs services::scheduler
• cargo test -p claude-code-rs --bin claude-code-rs services::onboarding
• cargo test -p claude-code-rs --bin claude-code-rs commands::loop_cmd
• cargo test -p claude-code-rs --bin claude-code-rs commands::schedule
• cargo test -p claude-code-rs --bin claude-code-rs commands::logout
• cargo test -p claude-code-rs --bin claude-code-rs commands::team_onboarding
• cargo test -p claude-code-rs --bin claude-code-rs commands::tests (registry)
• cargo test -p claude-code-rs --bin claude-code-rs -- --test-threads=1 (full suite serially)

Reviewer notes

• On-disk layout: scheduled tasks live at {data_root}/scheduled_tasks.json, guarded by a sibling .json.lock file; onboarding state at {data_root}/onboarding.json. Both use atomic write-to-tmp + rename so crashes mid-write don't corrupt state.
• SchedulerKind::RemoteTrigger is reserved in the enum even though it's rejected at insert time today — this means on-disk state survives when the remote capability lands, without a breaking schema change.
• /team-onboarding reads project state at invocation time; it never caches, so regenerating always reflects the current repo.

🤖 Generated with Claude Code