In `@src/commands/run.tsx`:
- Around line 2430-2435: filterTasksByRange currently only updates the local
tasks array but ExecutionEngine and ParallelExecutor call the tracker directly
and ignore that filter; propagate the filtered IDs into the execution selection
by obtaining the filtered task IDs from filterTasksByRange and passing them into
the engine/executor creation or run methods (e.g. pass filteredTaskIds into
ExecutionEngine.initialize/run or ParallelExecutor.run) or alter the tracker
query used by ExecutionEngine/ParallelExecutor to include the same range filter
(use options.taskRange or filteredTaskIds) so both engines only fetch and
execute the narrowed set of tasks; update references in the selection logic that
construct ExecutionEngine and ParallelExecutor to accept and forward the
filtered IDs.

In `@src/remote/client.ts`:
- Around line 450-458: The reconnect path drops 'parallel_event' messages
because attemptReconnect()'s onmessage handler doesn't route them; update
attemptReconnect's onmessage to mirror the main dispatcher by handling the
'parallel_event' case (treat message as ParallelEventMessage and call
this.eventHandler with type:'parallel_event', orchestrationId and event) or
refactor so attemptReconnect delegates incoming messages to the shared
dispatcher method (e.g., call the same handler used in the primary onmessage) to
ensure orchestration updates are processed after re-auth.

In `@src/remote/server.ts`:
- Around line 1364-1373: Validate and reject non-positive maxWorkers values
before creating ParallelExecutor: check message.maxWorkers (and the computed
maxWorkers) is an integer > 0, and if not either throw/return a clear error or
fall back to a safe default; update the code that sets maxWorkers (the variable
used to construct the ParallelExecutor instance) and ensure
ParallelExecutor.batchTasks can assume maxWorkers > 0. Reference: the maxWorkers
local variable, message.maxWorkers, and the ParallelExecutor class/batchTasks
method.

In `@src/commands/run.tsx`:
- Around line 381-414: The parser currently rejects "-10" because the case
'--task-range' branch checks !nextArg.startsWith('-'); update that guard to also
accept negative-number values (e.g. allow nextArg when it matches a
negative-integer pattern like /^-\d+$/) so end-only ranges like "-10" are
treated as a range string; keep the existing parsing logic that computes
dashIndex, parsedStart/parsedEnd and sets options.taskRange, and still advance
i++ after consuming the value.

In `@src/engine/index.ts`:
- Around line 590-596: The current early return stops the engine when the
tracker yields a task outside the allowed set; change the logic so that if
this.config.filteredTaskIds is defined and length === 0 you immediately return
null (explicit empty allowed list => yield no tasks), otherwise when a task
exists but its id is not in this.config.filteredTaskIds simply skip it and
continue the containing task-yielding loop until you find an allowed task or run
out; update the block referencing task and this.config.filteredTaskIds (inside
the method that obtains/yields tasks) to check for the empty-array case first,
and replace the `return null` on mismatch with a continue/skip so other allowed
tasks can still be found.

In `@src/remote/server.ts`:
- Around line 377-384: The disconnect handler currently calls
self.orchestrationSession.executor.stop() without awaiting it before calling
self.orchestrationSession.unsubscribe() and nulling self.orchestrationSession;
change this to await the stop() (e.g., await
self.orchestrationSession.executor.stop().catch(() => {})) before calling
self.orchestrationSession.unsubscribe() and setting self.orchestrationSession =
null so the stop completes (matching the handleOrchestrateStop pattern) and
avoids racing file I/O cleanup in ParallelExecutor.stop().

In `@src/engine/index.test.ts`:
- Around line 265-306: The test is failing because
ExecutionEngine.getNextAvailableTask treats a tracker-provided task outside
config.filteredTaskIds as end-of-queue; change getNextAvailableTask so that if
tracker.getNextTask() returns a task whose id is not in config.filteredTaskIds
it does not immediately return null but instead skips that task and finds the
next allowed one (either by calling tracker.getTasks() and selecting the first
open task whose id is in config.filteredTaskIds, or by iterating calls to
getNextTask until an allowed id is returned), and update the test expectation to
assert the engine returns a permitted task (e.g., task-1 or task-3) or null only
if no allowed tasks exist; refer to ExecutionEngine.getNextAvailableTask,
TrackerPlugin.getNextTask, TrackerPlugin.getTasks, and config.filteredTaskIds
when making the change.

In `@src/remote/server.ts`:
- Around line 1336-1387: handleOrchestrateStart currently analyzes the full task
list and constructs ParallelExecutor without honoring
baseConfig.filteredTaskIds, so filter the tasks returned from
this.options.tracker.getTasks by this.options.baseConfig.filteredTaskIds (or by
message-provided range) before calling analyzeTaskGraph; if the filter yields
zero tasks, send the 'orchestrate:start_response' failure as you do for no
actionable tasks; when creating the ParallelExecutor, include the filtered IDs
in its options (e.g. pass filteredTaskIds) so the executor only schedules those
tasks and reports correct totals (update the ParallelExecutor instantiation to
accept and forward filteredTaskIds).

In `@src/remote/server.ts`:
- Around line 1398-1421: Add a clarifying comment near the orchestrationSession
assignment explaining that session persistence after completion is intentional:
note that the executor subscription (executor.on -> unsubscribe) forwards events
via broadcastParallelEvent and only updates orchestrationSession.status, and
that actual cleanup happens on client disconnect (the existing disconnect
handler stops and clears orchestrationSession), so keeping the session object
allows clients to call "orchestrate:get_state" to inspect final state until the
session is explicitly stopped or the originating client disconnects.

In `@src/remote/server.ts`:
- Around line 1340-1351: The current check treats an empty array as "no filter"
and runs all tasks; instead, in the block using
this.options.baseConfig.filteredTaskIds (variable filteredTaskIds) explicitly
treat filteredTaskIds !== undefined as a provided filter: if filteredTaskIds ===
[] (length === 0) immediately return the failure response via
createMessage<OrchestrateStartResponseMessage>('orchestrate:start_response',
...) with an appropriate error like 'No tasks match the specified filter';
otherwise apply the Set filter to tasks as you already do. Update the logic
around tasks.length check so the empty-filter case is handled before filtering
and does not fall through to run all tasks.
- Around line 1314-1335: The orchestrate:start handler can race and create two
executors because this.orchestrationSession is only set after async work; add a
short-lived "starting" guard (e.g., this.orchestrationStarting) checked
alongside this.orchestrationSession at the top of the handler to immediately
reject concurrent starts, set this.orchestrationStarting = true before any
awaits/async calls that lead to creating the session, and clear it (set to
false) on all failure paths and after the session is successfully assigned to
this.orchestrationSession; update the response logic to return the same error
when orchestration is in progress or starting so the start becomes atomic.

In `@src/remote/server.ts`:
- Around line 1460-1461: The comment above the assignment to
this.orchestrationStarting should be reworded to remove temporal phrasing;
replace "Clear the starting guard now that session is established" with an
evergreen, state-focused comment such as "Clear the orchestration starting guard
after establishing the session" or "Reset orchestrationStarting to indicate
session is established"; update the comment immediately preceding the
this.orchestrationStarting = false; statement in server.ts (the line that sets
orchestrationStarting) accordingly.