Skip to content

Chapter 17 · Capstone 2: Multi-Project Parallel Delivery Pipeline ​

Chapter goals: Advance tasks across three different projects simultaneously, master firstmate's parallel routing, dispatch profile selection, and per-project merge permission management — turning "one fleet" into a delivery pipeline.

17.1 Scenario: Three Projects, Three Task Shapes ​

Single-task serial is just the起点. FirstMate's true价值 is: you describe what needs to be done, and the firstmate routes each request to an独立 session endpoint + independent git worktree,互不阻塞. This chapter sets three parallel工作 lines:

text
Project A (web-api)    : ship task — fix an偶发 500 bug
Project B (data-pipeline): scout task — read-only architecture audit, produce a report
Project C (cli-tool)   : ship task — add a small --version subcommand

These three lines覆盖 the two task shapes from Chapter 8 and the three project modes from Chapter 10 — a typical缩影 of daily use.

17.2 Issuing Multiple Tasks at Once ​

No need to排队 and交代 one by one. Use one natural-language message to clarify all three:

text
> three things in parallel:
> 1) web-api repo: fix the偶发 500 on /search, go through full validation and open a PR;
> 2) data-pipeline: read-only architecture audit only — data flow, module boundaries, tech debt清单,
>    produce a report; do not touch code;
> 3) cli-tool: add a --version subcommand, validate locally, then do a local merge.

What you should see: the firstmate restates and confirms understanding (including the task shape for each), then spawns up to three crewmates; multiple fm-task* windows appear in tmux; each window推进es independently, completion order不必一致.

Two mechanisms worth recalling here:

  • Worktree隔离 (Chapter 9): even if the three crewmates touch同名 files, they不会互相踩踏 because each has a clean独立 worktree;
  • Zero-token supervision (Chapter 11): the watcher sleeps in the background; only when someone completes orwedges does it wake the firstmate to report to you — no token burn during等待.

17.3 Dispatch Profiles: Choosing Different Harnesses per Task ​

By default, all crewmates use the same crewmate harness (config/crew-harness). When不同任务的性质差异很大, you can启用 dispatch profiles: an optional local gitignored file config/crew-dispatch.json, written in natural language rules that the firstmate reads before dispatching and uses its judgment to match.

json
{
  "rules": [
    {
      "when": "bug fix or a ship task needing the full test pipeline",
      "use": [{ "harness": "claude", "effort": "high" }],
      "why": "Fix tasks need strong tool calling and long context"
    },
    {
      "when": "architecture audit, code research scout tasks",
      "use": [
        { "harness": "pi", "model": "deepseek-chat" },
        { "harness": "grok" }
      ],
      "why": "Research prioritizes低成本高吞吐; array form做配额感知的备选"
    }
  ],
  "default": [{ "harness": "claude" }]
}

Official schema要点:

  • Each rule必须有 when and use; use and the top-level default both accept a single profile object or a非空数组 (array undergoes quota-array-dispatch for配额感知 selection);
  • model, effort (low|medium|high|xhigh|max), and rule-level why are all optional; omitting uses that harness's own default;
  • The shell script does not parse semantics — matching rules relies on the firstmate's judgment; the script only负责 passing the selected --harness/--model/--effort具体参数 to fm-spawn.sh and validating JSON shape (bootstrap uses jq validation;非法配置 reports CREW_DISPATCH: invalid ... diagnosis rather than being silently bypassed).

Twobehavior changes to know: once this file exists, fm-spawn.sh refuses any crewmate/scout launch without an explicit harness (config/crew-harness no longer auto-fallback); secondmate launch is exempt from this constraint, still走 config/secondmate-harness. Also, this file is inherited into secondmate homes, letting the entire fleet共享 the same dispatch strategy.

bash
# No restart needed after writing; auto-validates on next bootstrap
cat config/crew-dispatch.json | jq empty && echo "JSON OK"

17.4 Per-Project Merge Permissions: Three Modes in Place ​

From Chapter 10, each project's standing posture is recorded in data/projects.md. This chapter assigns the most suitable mode for each of the three projects:

ProjectModeRationale
web-apidirect-PRBug fix希望尽快出 PR 走 CI 复核; no-mistakes full pipeline not needed
data-pipeline(no ship)Scout tasks never push; no merge issue
cli-toollocal-onlySmall feature local quick-change; firstmate does a fast-forward local merge after your approval

The one-sentence official semantics for the three modes: no-mistakes runs the full validation pipeline; direct-PR skips the pipeline and opens a PR directly; local-only stays local until the firstmate performs an approved fast-forward merge. The optional +yolo flag grants merge autonomy — this chapter刻意 does not use it, so every merge passes through your hand.

One safety detail: if a ship task's执行严格度 is below the project's registered posture, spawn prints a deviation notice and continues — the registration is not装饰, deviations are显式 exposed.

17.5 Decision Backlog Handling: /ahoy and /bearings file include PRs ​

The more parallel tasks, the more decisions that升级 to you. Two built-in skills form your "值班仪表盘":

text
> /bearings file include PRs

This command generates the four-section summary and同时 writes a date-stamped version report to data/status-report-<YYYY-MM-DD>.md, enriched with real-time PR info — ideal as the first指令 of the workday.

text
> /ahoy

[truncated - see source for full content]

17.6 Chapter Summary ​

  • Multi-project parallel: one message → three independent worktrees → three crewmates → concurrent execution;
  • Dispatch profiles: config/crew-dispatch.json lets you选不同的 harness/model/effort per task type;
  • Per-project modes: web-api uses direct-PR, data-pipeline is scout-only, cli-tool uses local-only;
  • Decision仪表盘: /bearings file include PRs for overview; /ahoy for guided decision handling;
  • Zero-token supervision keeps the watcher sleeping until something actionable happens.

🧪 随堂测验

点击你认为正确的选项。答错时会展示正确答案与原因解析。

1. What does dispatch profile do?

2. What happens once config/crew-dispatch.json exists?

3. Why use local-only mode for the cli-tool project?

4. What is the role of /bearings file include PRs in this capstone?

🛠️ Hands-On Exercises ​

  1. Set up three practice repos (web-api, data-pipeline, cli-tool); write a dispatch profile that routes bug fixes to Claude/high and research to Pi/deepseek; dispatch all three tasks in one message and verify concurrent execution.
  2. Verify per-project modes: check that web-api's ship task uses direct-PR, cli-tool's uses local-only, and data-pipeline's is scout-only.
  3. Run /bearings file include PRs mid-execution; verify the report file is created with PR enrichment.

Capstone 2 complete. Next: Capstone 3: Secondmate Remote Fleet Scaling.