feat: verify devin CLI as a harness adapter

[hayssamhob]

Summary

• Add devin CLI (v2026.8.18) as a firstmate harness adapter, empirically verified via a supervised scout task
• All supervision primitives work: detection, locking, spawning, turn-end signaling, busy detection, composer idle detection, interrupt, exit, and skill invocation

Changes

• fm-harness.sh: detect devin via process ancestry; fix basename dash bug (comm may start with -, e.g. -zsh) by using ${comm##*/}
• fm-lock.sh: add devin to HARNESS_RE; same basename fix
• fm-spawn.sh: devin launch template (--prompt-file + --permission-mode dangerous) and .devin/hooks.v1.json Stop hook for turn-end signaling
• fm-tmux-lib.sh: FM_TMUX_COMPOSER_IDLE_RE_DEFAULT with devin placeholder patterns (devin uses RGB color ESC[38;2;124;124;124m, not SGR 2 dim, for placeholder text)
• harness-adapters skill: verified devin knowledge section

Key findings

Devin renders its composer placeholder text ("Ask Devin to build features...") using a dark 24-bit RGB color, not the SGR 2 dim/faint attribute that claude uses. The dim-aware ghost stripper in fm-tmux-lib.sh only drops SGR 2 runs, so it cannot catch devin's placeholder. The new FM_TMUX_COMPOSER_IDLE_RE_DEFAULT provides the targeted backstop.

Devin reads Claude Code-compatible hooks from .devin/hooks.v1.json, where the hooks object IS the entire file (no "hooks" wrapper key). The Stop event fires at every turn boundary.

Test plan

• bash tests/fm-composer-ghost.test.sh - all 9 assertions pass
• Full test suite (13 test files) - all pass
• Empirical verification: spawned scout task devin-verify-4q, confirmed turn-end hook fires, busy detection works, composer idle detection works, worktree isolation guard passes
• bash -n syntax check on all modified scripts

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.

[kunchenguid]

thanks for this. quick note on process - i require PRs to come through no-mistakes, which is why the "PR must be raised via no-mistakes" check is red here (this was opened directly).

the reason i ask for it: no-mistakes runs review, tests, lint, and docs on your branch before the PR is opened, so contributions arrive already validated. that keeps the quality bar high and keeps me from having to hand-review every change - i maintain this solo, so it's the only way i keep up.

can you re-raise it through no-mistakes? running the pipeline on your branch opens/updates the PR through the gate and turns that check green. the change looks useful, it just needs to come through that path. ping me if the setup gives you trouble.