… steps in parallel mode as in sequential mode

With parallelMode, the step path only converted the Cucumber status:

- an undefined step was reported as passed, with no error
- an ambiguous step was skipped with no reason, and
  failAmbiguousDefinitions was ignored for steps
- a failed step had the whole Cucumber message as error message, so
  reporters showed `Error: Error: ...` and internal stack lines

The parallel step path now uses getStepResult(), as the sequential
formatter does, and lists the matching step definitions of an ambiguous
step from Cucumber's support code messages.

Real-browser check (Chrome, sequential vs parallel run of the same
specs): the spec, dot, concise, JUnit and JSON reporters now give the
same step results, also with ignoreUndefinedDefinitions and
failAmbiguousDefinitions.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Parallel mode ran the scenarios in file order and ignored
cucumberOpts.order. It now orders them with Cucumber's own
orderPickles, as Cucumber does in a sequential run: `random:<seed>`
gives the same order as a sequential run, `random` logs its seed, and
an unknown order fails before any window opens.

Real-browser check (Chrome, 2 feature files, order random:7, 1 slot):
sequential and parallel runs start the scenarios in the same order.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

…itle in parallel mode

In parallel mode a Before/After hook had an empty title. Sequential
mode titles it with the hook name and tag expression, for example
`@beforeFails`, which the spec reporter shows for a failing hook and
the JSON reporter writes as the hook title.

The hook titles now come from the same support code messages as the
step definitions.

Real-browser check (Chrome, sequential vs parallel run of the same
specs): the spec, dot, concise, JUnit and JSON reporters give the same
result.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

…os in parallel mode as in sequential mode

With scenarioLevelReporter, the parallel scenario result kept its own
rules and collected an ambiguous step result before its message was
added:

- with failAmbiguousDefinitions, an ambiguous scenario failed with no
  error, and when skipped it had no pendingReason
- with ignoreUndefinedDefinitions, the scenario title had no
  ` (undefined step)` suffix
- the undefined scenario message had quotes and no scenario location

The scenario result now uses getStepResult(), as the sequential
formatter does, with the ambiguous message added first.

Real-browser check (Chrome, scenarioLevelReporter, also with
failAmbiguousDefinitions and ignoreUndefinedDefinitions): the spec,
dot, concise and JSON reporters give the same result in sequential and
parallel runs.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

…n parallel mode

With tagsInTitle, a parallel feature suite had no tags in its title
(`Statuses in parallel` instead of `@feat: Statuses in parallel`), and
its start had no description and keyword. Reporters such as JUnit and
spec then named the feature differently than in a sequential run.

Real-browser check (Chrome, tagsInTitle, step and scenario level): the
JUnit testsuite names and the spec failure titles are the same as in a
sequential run.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

…stop as Cucumber does

After a failFast stop, parallel mode reported each scenario that did
not run as plain skipped steps. Cucumber runs these scenarios in skip
mode: their hooks are reported as skipped, an undefined step stays
failed, and an ambiguous step keeps its reason.

They now run through Cucumber's test case runner with `skip: true`,
with no window, so the reporters get the same events as in a
sequential run. The failFast tests use a defined failing step, because
in skip mode an undefined step stays failed.

Real-browser check (Chrome, failFast, step and scenario level, 2
slots): the spec, dot, concise, JUnit and JSON reporters and the
framework events are the same as in a sequential run.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

…el mode

`--spec file.feature:12` failed in parallel mode with ENOENT: the
adapter read the feature file with the `:12` suffix. With the file read,
every scenario of the file still ran, because Cucumber's line filter
compares the uri relative to the cwd and parallel pickles have an
absolute uri.

The adapter now reads the file without the line numbers and keeps them
in the specs for the line filter, which gets the pickle uri relative to
the cwd.

Real-browser check (Chrome, `--spec statuses.feature:6:22`, and 2 files
with 1 line each): the same scenarios run as in a sequential run, and
the reporters give the same result.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Name what parallel mode reports like a sequential run (also with
ignoreUndefinedDefinitions, failAmbiguousDefinitions, tagsInTitle and
scenarioLevelReporter) and that specs with line numbers work, and list
the differences found in a real-browser matrix: failFast lets running
scenarios finish, ignoreUndefinedDefinitions does not make an ambiguous
or strict pending step pass the run, and Cucumber formatters write no
file.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

…arallel mode

A pending step (also an undefined step with ignoreUndefinedDefinitions)
had `passed: true` in its parallel payload, and `passed: false` in the
sequential one. Parallel mode now uses the sequential rule: only a
passed or skipped step is passed.

Real-browser check (Chrome, ignoreUndefinedDefinitions): both pending
steps had passed=false in the sequential run and passed=true in the
parallel run before this change.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

…or sequential and parallel runs

The formatter and the parallel step path each added the matching step
definitions to an ambiguous result in their own code. Both now use
withAmbiguousMessage() in utils.ts, which looks up the step only for an
ambiguous result with no message.

No change in the output: the formatter tests and snapshots, the smoke
suites and a real-browser run with failAmbiguousDefinitions give the
same result.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Checked each option against the code and real runs:

- `timeout` defaults to 60000, `backtrace` to false (Frameworks.md said
  30000 and true)
- `strict` fails the run on a pending step; an undefined step fails it
  also without `strict` (Cucumber's shouldCauseFailure)
- `retryTagFilter` is a tag expression string, not a repeatable RegExp
- `ignoreUndefinedDefinitions` reports the step as pending with the
  ` (undefined step)` suffix and does not fail the run
- `order` explains `random:<seed>`
- a feature file with no matching tag starts no browser session (the
  runner stops before the session when the framework has no tests)
- the option is `profiles`, not `profile`; `file`, `dryRun`,
  `worldParameters` and `scenarioLevelReporter` were not documented, and
  the README did not have `parallelMode` and `maxParallelContexts`
- formatters and the message report for publishCucumberReport are not
  written with `parallelMode`
- Retry.md: Cucumber `retry` works without `scenarioLevelReporter`

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

…e step result rule

getStepResult() checked `willBeRetried` on a step result. Cucumber sets
this field only on the testCaseFinished message and the hook parameter,
never on a step result, so the check was always true. Retries still
work through testCaseFinished.willBeRetried, in both modes.

Docs: with ignoreUndefinedDefinitions, an ambiguous step fails a
parallel run but not a sequential one only with
failAmbiguousDefinitions: false (with true, both runs fail).

Real-browser check (Chrome, retry, retryTagFilter, scenario-level
retry): exit codes and the framework events are the same as in a
sequential run.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

With order: 'random', loadSources in init() and the run each picked a
seed. The sequential run logged the seed of loadSources (its own log
goes to a discarded stream), so the logged seed did not give the order
of the run again; a parallel run logged 2 seeds. init() now sets
random:<seed> and logs that seed.

…ported yet

Overlapping scenarios are nested and the passing count after a retry
can be wrong; the scenario results and the exit code are correct.