Chapter 4 · The Five Hard Rules and Safety Boundaries

Chapter goals: Understand the five Hard Rules in the FirstMate operating contract (AGENTS.md) one by one, clarify the boundary each rule protects, the允许 exceptions, and how they共同构成 the safety foundation for "confident delegation."

4.1 Why Hard Rules Exist

In the previous chapter we saw that AGENTS.md defines the firstmate as "the captain's sole liaison." This means you're handing over engineering actions with side effects — fixing bugs, reviewing code, parallel development — to an agent fleet.

The premise of delegation is clear boundaries. If the firstmate can随意 modify your project, merge PRs at will, or discard uncommitted work, then "Talk to one agent" is not efficiency — it's risk. So AGENTS.md lists a priority-ordered hard rules清单 in Section 1 (Identity and prime directives):

Hard rules, in priority order:

1. Never write to a project.
2. Never merge a PR without the captain's explicit word.
3. Never tear down unlanded work.
4. Crewmates never address the captain.
5. Report outcomes faithfully.

The common trait of these five rules: they are强制 constrained by contract text, not left to the model's自觉. AGENTS.md is the firstmate's "job description"; once the harness loads this file, the rules生效 on every session.

Let's拆解 each one.

4.2 Hard Rule 1: Never Write to a Project (Never write to a project)

This is the most core rule: the firstmate itself does not edit, commit, or execute state-changing operations under projects/. It reads projects, dispatches tasks, and supervises crewmates; the ones actually改动 project code are the delegated crewmates.

firstmate  reads projects/ + routes tasks      (read-only + routing)
crewmates  make every project change           (crewmates do the work)
captain    makes every merge decision          (captain decides merges)

Of course, a complete ban would make some ops actions impossible, so this rule comes with a set of narrow and guarded exceptions:

• Guarded project initialization;
• Fleet sync, secondmate sync, and propagation of inherited local materials;
• Self-update;
• Approved local-only merge paths;
• Captain's on-the-spot explicit approval for concrete project operations.

Note the strictness of exceptions: these paths do not implicitly authorize force push, stash, or discard of unlanded work; nor do they allow the firstmate to手写 the project's AGENTS.md. Even in captain-approved scenarios, the request must be "当下、针对具体项目、具体操作或无歧义的具体范围" — the firstmate only执行 the approved action本身 — no inference, no scope expansion, no standing permission留.

4.3 Hard Rule 2: No Merge Without the Captain's Explicit Word

Rule 2 governs the delivery endpoint: any PR merge must originate from the captain's explicit表态. In practice, this is the phrase "alright merge it."

The only standing relaxation is the yolo merge-autonomy posture in the project config — it is a project-level switch the captain事先批准, equivalent topre-delegating a class of merge authority. Aside from this, merge authority始终 stays with the captain. Chapter 10 (project modes: no-mistakes / direct-PR / local-only and the +yolo flag)展开 this mechanism.

4.4 Hard Rule 3: Never Destroy Unlanded Work (unlanded work)

Rule 3protects work products: uncommitted changes are never清理'd, and the determination of "whether a stretch of work has been landed" belongs to bin/fm-teardown.sh (which implements the full landed-work test). The firstmate is not allowed to bypass the rejection result or use --force, unless the captain explicitlyauthorizes discarding that work.

For scout-task临时 worktrees there's a专门约定: only when the recon report has been produced AND the shared unresolved-decision completion threshold is passed, can it be declared scratch and discarded.

# Conceptual示意: teardown is gated by the script, not ad-hoc rm
bin/fm-teardown.sh   # Built-in landed-work test; unlanded work is rejected for cleanup

This rule and Hard Rule 1 together form two闸门 for data security: project content is not改 by unauthorized hands, and existing成果 are notdestroyed by unauthorized hands.

4.5 Hard Rules 4 and 5: Communication Topology and Faithful Reporting

The last two rules规范围的是 信息流:

Rule 4: Crewmates never address the captain. All crewmate communication goes through the firstmate; crewmates never shout directly to the captain. If the captain直接介入 a crewmate's session window, that intervention is treated as authoritative指令 and is reconciled by the firstmate at the next supervision review. This guarantees you always have only one对话入口 — this is exactly what distinguishes FirstMate from "opening a bunch of terminal tabs."

Rule 5: Report outcomes faithfully. If work fails, say it failed — with evidence. A supervisor's value depends on the可信度 of its reports; a fleet that粉饰太平 is more dangerous than no fleet.

you ──chat──> firstmate ──brief──> crewmates
 ^                  │                    │
 │                  ▼                    │
 └──── decisions ◄── escalation ◄── status ─┘   (crewmates never bypass firstmate to reach you)

4.6 Violation Scenario Drill

Test the five rules against real scenarios:

Scenario	Correct Behavior	Basis
You say "fix the typos in the README"	Firstmate delegates a crewmate to fix;它不动文件	Hard Rule 1
CI is green, you say "use your judgment"	Cannot merge; "use your judgment" does not constitute an explicit merge指令	Hard Rule 2
Project has +yolo,小 changes auto-merge	Can merge per the established posture	Hard Rule 2's yolo relaxation
Task fails,半成品修改 in the worktree	Reject cleanup and escalate; wait for your decision	Hard Rule 3 + 5
You directly type a指令 in a crewmate's tmux window	The指令 is authoritative; reconciled at the next supervision review	Hard Rule 4
Crewmate task actually failed but looks "roughly done"	Report failure faithfully with evidence; no含糊其辞	Hard Rule 5

You can see that the five rules respectively锁住 five危险面: write权限, merge authority, delete authority, communication topology, honesty obligation. Understanding them tells you what to say to the firstmate and which decisions tokeep for yourself.

4.7 Chapter Summary

• Five hard rules in priority order: no write to project, no merge without captain, no destroy unlanded work, crewmates don't直达 captain, report faithfully;
• "No write to project" has narrow guarded exceptions (init/sync/self-update/captain on-the-spot approval); exceptions never implicitly authorize force, stash, or discard;
• Merge authority defaults to the captain; yolo is the only standing relaxation pre-approved by the captain;
• Unlanded work determination is gated by bin/fm-teardown.sh; bypassing rejection or --force requires explicit captain authorization;
• The single-liaison model relies on Hard Rule 4 for communication topology and Hard Rule 5 for report可信度.

🧪 随堂测验

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

1. Under Hard Rule 1, what is the firstmate's basic posture toward the projects/ directory?

2. Regarding PR merge authority, which statement is correct?

3. A scout task's worktree still has uncommitted changes; the firstmate wants to clean it up. What is the correct approach?

4. You直接 type an指令 in a crewmate's tmux window. According to Hard Rule 4, what happens?

🛠️ Hands-On Exercises

1. Open the cloned firstmate repo; read the five Hard Rules原文 in AGENTS.md Section 1; write a one-sentence Chinese summary for each rule and标出 the risk each防范.
2. After launching firstmate,故意 issue an ambiguous merge指令 (e.g., "CI green so use your judgment"); observe its reaction; then对比 with an explicit "merge it";记录 which one actually触发 the merge流程.
3. In a测试 project, leave uncommitted changes in a task's worktree; request the firstmate to clean the对应 worktree; verify it拒绝 cleanup based on the landed-work test; then explicitly authorize discard and观察 the full authorization-execution链路.

Rules understood. Next, the runtime layout: FM_HOME and directory conventions.