updatefirstmate

Self-update firstmate in place. Firstmate is its own repo, behind the same no-mistakes gate as any project, so new tracked material (AGENTS.md, bin/, .agents/skills/, and public skills/) reaches main and then sits there until each running firstmate pulls it. Only AGENTS.md, bin/, and .agents/skills/ are a running firstmate instruction surface; public skills/ is installer-facing and is not loaded by firstmate. This skill performs that pull for the running main firstmate and every secondmate, without disturbing any in-flight work. Updating is consumption, not publication: it only pulls from upstream, so every home runs it regardless of role, and the firstmate-repository publication boundary (firstmate-self-repo) never applies to it.

Pulling the files is only half of it. A running agent holds AGENTS.md and every skill it has already loaded frozen from the moment it launched, and no verified harness offers a reload, so new bytes on disk change nothing for it until it starts a fresh conversation. A re-read cannot substitute: it appends a second copy of the mate's own job description with no defined precedence, and it cannot reach a skill that is already loaded. Replacing the agent is also the only thing that re-resolves the launch-time wiring - turn-end hooks, harness flags, per-harness feature switches - which the mate froze when it started and which nothing on disk describes.

That is why every live second mate is restarted after a successful update, including one that was already on the target commit. Launch-time wiring is not derivable from a file diff, so an unchanged tracked surface is not evidence the running agent is already on the current behavior. The only live mates that do not restart are the ones whose home the update pass had to skip, and the ones whose runtime cannot prove a restart; the updater keeps both cases honest and neither is reported as a reload.