fix(flow): allow resuming flows with bash steps (v1.55.1)

[siddharth-bhansali]

INT-4409 · found while triaging #186

Problem

one flow resume <runId> was registered with zero options (cli.ts:572), and flowResumeCommand called runner.resume(flow, api, permissions, actionIds, { onEvent, rootDir }) — no allowBash (flow.ts:605).

FlowRunner.resume already takes FlowExecuteOptions, which supports the field. It was simply never populated, and no flag existed to populate it from. So resuming any flow with a bash step threw:

Bash steps require --allow-bash flag for security

with no way to satisfy it. Resume is the recovery path for a paused or failed run, so a bash flow that failed was permanently unrecoverable.

Found while triaging #186 (Clockwork), where 76 of 110 flows use bash steps and run on a scheduler — exactly the case where a failed run needs resuming. (The four defects in #186 itself are all Clockwork's; nothing there needs a CLI change.)

Changes

• Registers --allow-bash on flow resume and threads it through to runner.resume.
• Adds the same fail-fast pre-flight flow execute runs, so a caller gets {error, requiresBash, flowKey, runId} up front rather than a mid-run engine error partway through a partially-completed resume.

The permission is deliberately not inherited from the original run — resuming re-grants shell execution, so it should be re-stated. Documented in README and flows.md.

Second fix — required to test the first

src/commands/update.ts resolved require('../package.json') from two levels down. That path only exists in the bundled dist/ layout; from source it resolves to src/package.json, which doesn't exist. It threw MODULE_NOT_FOUND at import time, so importing the command tree — and therefore any test of the commander registration — died before running. This is why the command layer has almost no tests.

src/lib/analytics.ts had the identical bug but swallowed it in a try/catch, silently reporting every telemetry event from a source checkout as version "unknown".

Both now use lib/version.ts, which walks upward for package.json the same way builtin-profiles.ts already locates profiles/. It's a genuine (small) scope addition, and I'd rather flag it than bury it — but the alternative was shipping the fix with no test of the thing that was broken.

Verified in both layouts, since that was the regression risk:

• the suite now imports the command tree from source
• node bin/cli.js --version on the rebuilt bundle still reports 1.55.1
• node bin/cli.js flow resume --help lists --allow-bash

Tests

8 new; 465 total, 0 skipped, all passing.

The registration tests assert attributeName() maps to allowBash and matches how flow execute declares the same flag — registering a flag but reading a differently-named property would leave it undefined, the gate would still reject, and nothing would look wrong. That's the failure mode worth pinning, not merely "an option exists".

[linear]

INT-4409