[vishnuv688]

What & why

Closes #528 (the last of three cleanup PRs). Part of #494. Stacked on #521.

A duplicate-block scan found the same code in two or three adapters, word for word, plus repeats inside single adapters. Each true duplicate now lives once. No behaviour change: log text, logger names and every adapter's BiDi attach behaviour are as before.

Type of change

• Bugfix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Polish (an improvement to an existing feature)
• Breaking change (existing behavior changes for users)
• Documentation
• Internal (build, CI, dependencies, tooling)

Packages touched

• shared (types and contracts)
• core (framework-agnostic capture/reporting)
• elements (published element/snapshot API — @wdio/elements)
• service (WebdriverIO adapter)
• nightwatch-devtools (Nightwatch adapter)
• selenium-devtools (Selenium adapter)
• selenium-devtools-py (Selenium Python adapter)
• backend (server)
• app (UI)
• script (page-injected runtime)
• trace (Trace mode)

Capability matrix

• packages/conformance/src/features.ts updated, and tables regenerated with pnpm docs:capabilities, if this adds or changes user-facing behaviour

Not needed: no behaviour change.

Notes for reviewers

Why this is in core, though it touches every adapter: the screencast lifecycle logging existed in three adapters and the BiDi sink wiring in two, word for word, so a change to either had to land in every copy, which is CLAUDE.md's rule for core. Each adapter still owns what is its own: its logger name, Nightwatch's screenshot transport, and Selenium's console evidence latch.

Finding	Decision
Screencast start, stop and unavailable log lines, 3 copies	Core. ScreencastRecorderBase writes them through a logger each adapter sets (ScreencastLogger), so logger names are unchanged; no logger means silent, as before
Selenium and Nightwatch buildBidiSinks	Core, copied verbatim. Selenium's console evidence latch (bidiConsoleObserved) stays in Selenium, passed in as onConsoleEntry. Each adapter's attachBidiHandlers wrapper stays: it only binds its logger name
Selenium mocha, cucumber and jest run summaries	One helper in the adapter, runnerHooks/run-summary.ts (jest's log text is identical, as it always reports 0 pending)
Selenium and Nightwatch PluginInternals repeating their context types	extends the context interfaces, redeclaring only fields whose readonly differs. Type-only
Nightwatch captured and replaced command rows	One private #commandEntry; a retry still keeps the previous row's id
WDIO launcher and standalone argv parsing	service/src/invocation-args.ts, its own module because the launcher patches http.Server.prototype.listen at load during a rerun, which must not reach the worker bundle
Selenium and Nightwatch types.ts	Kept: re-exports of shared types under stable local names, as CLAUDE.md endorses

Scan, pairs involving an adapter: 14 before, 2 after (the types.ts re-exports, and the backend vs Nightwatch config-file search kept in #521).

New core exports: ScreencastLogger, buildBidiSinks, BidiSinkTarget. The one renamed function, detectInvocationConfigPath to configPathFromArgv, was documented as not public API, so no changeset. None of these has a Python mirror.

Testing

• pnpm install --frozen-lockfile, pnpm build, pnpm test (3437 passed, twice, to rule out the flaky conformance failure seen once while developing) and pnpm lint are green.
• Dist leak grep: every .js/.cjs file in the service, Selenium and Nightwatch bundles searched, none found.
• New tests: the recorder's log lines with and without a logger; buildBidiSinks hook order, latch, and replace vs append; the run summary lines and payload.

Screenshots / recordings

Not applicable: no UI change.

🤖 Generated with Claude Code