Orca teardown refuses every task after #1171: composite orca_worktree_id fails fm_backend_endpoint_atom_valid

[localxcrm]

What happens

After updating to c0c0881, every Orca-backed task refuses teardown:

REFUSED: Orca endpoint metadata for task <id> is malformed or inconsistent; preserving task state.

The metadata is not malformed. It is exactly what bin/fm-spawn.sh wrote.

Cause

fbece9c (#1171, "harden endpoint cleanup") routes the Orca branch's orca_worktree_id through fm_backend_endpoint_atom_valid (bin/fm-backend.sh:380), which rejects any value containing a character outside A-Za-z0-9._@%+-:

fm_backend_endpoint_atom_valid() {  # <value>
  case "$1" in
    ''|*[!A-Za-z0-9._@%+-]*) return 1 ;;
  esac
}

But Orca's worktree id is a composite <uuid>::<absolute-path>, written by fm-spawn.sh:297 / :1464:

orca_worktree_id=e72d88c7-db30-4ae0-89e1-e826fe4ce584::/Users/rodrigocampos/orca/workspaces/estimate-os/fm-audit-est-product-security

: and / are both outside the allowed set, so the check can never pass for a well-formed Orca task. The validator is correct for single-atom endpoints such as a tmux pane or a terminal handle (terminal= passes fine); it is simply the wrong predicate for this composite field.

Impact

Teardown is the only guarded path that closes a task, and it now refuses for every Orca task on a home that has updated. Landed work cannot be cleaned up, task metadata stays live, and the watcher keeps raising stale wakes for a finished task indefinitely — one supervision turn burned per wake.

The refusal is safe (it preserves state rather than destroying anything), but it is unconditional, so --force is the only way past, which is exactly the wrong habit to build around an unlanded-work guard.

Reproduce

1. Spawn any scout or ship task with --backend orca.
2. Let it finish and land.
3. Run bin/fm-teardown.sh <id>.

Observed on firstmate c0c0881, macOS 25.5.0, bash 3.2. Three Orca tasks torn down cleanly on a5fe1bc earlier the same day; the first teardown attempted after the update refused.

Suggested fix

Validate the two halves separately rather than treating the composite as one atom — the uuid half against fm_backend_endpoint_atom_valid, and the path half against whatever the tmux/herdr worktree paths already use. That keeps the hardening intent (#1171 is guarding against injected or ambiguous endpoint values) without rejecting the format firstmate itself produces.

[ironerumi]

Same-class data point from a second backend shape, in case it helps generalise the fix.

We hit the identical wall on a downstream fork that carries an extra task kind — an "ad-hoc primary-session ship", registered by a local bin/fm-task-register.sh rather than by fm-spawn.sh. That kind by definition has no runtime endpoint at all: it deliberately records harness=adhoc with empty window=, worktree=, and tasktmp=, because the work runs in the primary session and there is no pane, terminal, or worktree to close.

After taking fbece9c (#1171), every such task refuses teardown at the same gate:

REFUSED: task adhoc-merge has a missing, empty, or ambiguous window endpoint; preserving task state.
not ok - merge-and-cleanup: ad-hoc cleanup failed

Different field, different backend, same root shape as this issue: fm_backend_validate_task_endpoint (bin/fm-backend.sh:386) is a single-atom, always-present contract, wired as the first cleanup authorization check in bin/fm-teardown.sh. It refuses records that firstmate itself produced whenever the endpoint is legitimately composite (your orca_worktree_id) or legitimately absent (our endpoint-less kind). In both cases the metadata is exactly what the writer intended; the predicate is just the wrong one for that shape.

And as you note, the refusal never self-clears — it takes the preserve-state branch, so --force is the only way past, which is precisely the wrong reflex to build around an unlanded-work guard.

Our local workaround, for whatever signal it carries: rather than teaching the shared validator about the new kind, we branched at the call site in fm-teardown.sh and gave the endpoint-less kind its own metadata-only authorization with the same fail-closed semantics — exact single non-empty value per field, same preserve-state refusal wording, plus positive assertions that window/worktree/tasktmp are empty so a drifted or forged record cannot use the carve-out to skip validation and still reach branch deletion and worktree return. That kept the hardening intent of #1171 intact while not rejecting a shape the tool itself writes.

Both cases point the same way as your suggested fix: the gate needs a per-shape endpoint contract — validate each backend's endpoint in the form that backend actually records (split composites into their parts, and let a kind that owns no endpoint prove that positively) — rather than one atom predicate applied to whatever string happens to be in the field. Happy to share the exact diff if a shared seam for endpoint-less or composite kinds is of interest.

Observed on a fork synced through 41ffd45; the upstream gate is unchanged at 99533c5. macOS 15.7.7, Darwin 24.6.0, bash 3.2.57 / 5.3.9.

[ami230392]

Independent reproduction on a separate fleet, plus one detail that may not be in the original report: --force does not bypass this, so there is no sanctioned escape hatch.

Reproduction

Three Orca-backed tasks, all spawned normally through bin/fm-spawn.sh --backend orca. Every one records the composite id:

orca_worktree_id=c205a482-eb96-4efc-ac49-f488b3519718::/Users/apple/orca/workspaces/<project>/<task>

bin/fm-teardown.sh <id> refuses:

REFUSED: Orca endpoint metadata for task <id> is malformed or inconsistent; preserving task state.

Confirmed directly against the validator:

. bin/fm-backend.sh
V="c205a482-eb96-4efc-ac49-f488b3519718::/Users/apple/orca/workspaces/x/y"
fm_backend_endpoint_atom_valid "$V"   # returns 1

fm_backend_endpoint_atom_valid (bin/fm-backend.sh:380) rejects anything outside A-Za-z0-9._@%+-. The composite id contains both : and /, so it can never pass. The value is written by fm-spawn itself, so firstmate is refusing an id it authored.

--force does not help

bin/fm-teardown.sh <id> --force produces the identical refusal. Per the script header, --force skips "ordinary-task dirty and landed-work checks" — but the endpoint-metadata validation runs earlier, in fm_backend_validate_task_endpoint, and is unconditional.

So for Orca tasks there is currently no teardown path: not the normal one, not the forced one. The only remaining option is manual worktree deletion, which .agents/skills/firstmate-orca explicitly advises against ("Avoid raw deletion of Orca worktrees or manual branch cleanup"). That leaves an operator with a supported instruction to not do the only thing that works.

Regression window

Bisected on this machine: the function is absent at eb9ee2f and present at c0c0881, introduced by fbece9c ("fix: adapt Grok Stop continuation and harden endpoint cleanup", #1171).

Confirming it is a regression rather than a long-standing gap: this fleet's other Orca project directories are empty, so teardown demonstrably worked before the update. The tasks stranded here are only those created after it.

As of origin/main five commits ahead of c0c0881, no commit touches bin/fm-backend.sh, so the fix does not appear to have landed yet.

Note on the other backends

The same fm_backend_endpoint_atom_valid gate is applied to the herdr, zellij, and cmux branches in the same function. Whether those are affected depends on whether any of them also record a composite id containing a path or separator — worth checking alongside the Orca fix rather than after a second report.

Environment

macOS 23.6.0 (Darwin), bash 3.2 system shell, Orca backend, harnesses claude and codex.