[adr] BiDi is an implementation mechanism, not a public API by titusfortner · Pull Request #17670 · SeleniumHQ/selenium

titusfortner · 2026-06-11T13:43:10Z

📄 The decision, its rationale, considered options, and consequences are in the record file this
PR adds (docs/decisions/17670-bidi-is-an-implementation-mechanism.md); read it there. The
sections below are proposal notes and review logistics.

🔗 Related

[🚀 Feature]: [bidi] Mark BiDi implementation classes and methods as internal across bindings #17628 — per-language mechanism for marking BiDi implementation internal.
[🚀 Feature]: [dotnet] [bidi] Finalize public API to prevent further breaking changes #16095 — .NET's effort to finalize BiDi as a public, supported API; this record sets the opposite default (BiDi internal), so it redirects that work.
[🚀 Feature]: Convenience methods for BiDi #13991 — earlier "Convenience methods for BiDi" feature request (closed); background to the high-level, protocol-neutral direction.
[docs] decision: BiDi is exposed in three API layers #17709 — competing ADR proposing a three-layer model with a supported explicit-BiDi layer; gives the opposite answer to this record. To be reconciled.
Prior discussion: implement warnings section for internal BiDi reference seleniumhq.github.io#2659.

📝 Proposal notes

Decide alongside [docs] decision: BiDi is exposed in three API layers #17709, not in isolation. This record's rejected option Fuzzbal #2 (a supported, separate BiDi namespace) is what [docs] decision: BiDi is exposed in three API layers #17709 proposes as its supported "Layer 2." The two are mutually exclusive answers to one question — is there a supported explicit-BiDi layer, or is all BiDi internal? Approving one rejects the other's premise; weigh them together.
This answer gates the BiDi module-ADR series (17671–17677, 17681, per [docs] decision: BiDi is exposed in three API layers #17709): accepting this record places those modules as internal implementation, not supported surface.

🗣 Discussion

📌 Tracking

Tracking issue: (linked on acceptance)

qodo-code-review · 2026-06-11T13:43:22Z

Code Review by Qodo

🐞 Bugs (4) 📘 Rule violations (0) 📜 Skill insights (0)

Context used

✅ Compliance rules (platform): 11 rules

1. Missing ADR date 🐞 Bug ⚙ Maintainability ⭐ New

Description

The ADR header omits the required "Date" field, so readers can’t tell when the status last changed.
This deviates from the project’s ADR template and reduces decision-log auditability.

Code

docs/decisions/17670-bidi-is-an-implementation-mechanism.md[R3-5]
+- Status: Proposed
+- Discussion: https://github.com/SeleniumHQ/selenium/pull/17670
+

Evidence
The new ADR header includes Status and Discussion but not Date, while the repository’s ADR template
explicitly requires a Date field in the header.
docs/decisions/17670-bidi-is-an-implementation-mechanism.md[1-5]
docs/decisions/0000-template.md[6-9]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
The ADR header is missing the `- Date: YYYY-MM-DD` field required by the ADR template.

### Issue Context
The template specifies that the header must include a date indicating when the status last changed.

### Fix Focus Areas
- docs/decisions/17670-bidi-is-an-implementation-mechanism.md[3-5]

### Suggested change
Add a `- Date: <YYYY-MM-DD>` line (the date the status last changed) between `Status` and `Discussion`.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

2. No binding status section 🐞 Bug ⚙ Maintainability ⭐ New

Description

The ADR lacks the required "Binding status" section/table for tracking convergence, and instead
tells readers tracking is in an issue linked from the PR. This conflicts with the documented ADR
process and makes the record less self-contained for implementers.

Code

docs/decisions/17670-bidi-is-an-implementation-mechanism.md[R83-87]

+- Users never need to know which protocol services a command.
+- Each new capability requires API design work across bindings before it ships.
+- Existing public surfaces that fail the conformance tests are brought in line per the
+  deprecation policy, tracked in the ADR implementation-tracking issue linked from this
+  record's PR.

Evidence
The ADR template and README define a dedicated Binding status section/table for tracking
convergence, but the new ADR ends after Consequences without it and instead references tracking from
the PR thread.
docs/decisions/17670-bidi-is-an-implementation-mechanism.md[81-89]
docs/decisions/0000-template.md[39-50]
docs/decisions/README.md[43-45]
docs/decisions/README.md[63-65]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
The ADR does not include the template-required `## Binding status` section/table (with per-binding status and notes/tracking links). It also points readers to tracking “linked from this record’s PR” instead of embedding tracking in the record.

### Issue Context
Repo documentation says bindings track convergence in the decision’s binding-status table, and the template provides the exact section/table to include.

### Fix Focus Areas
- docs/decisions/17670-bidi-is-an-implementation-mechanism.md[17-23]
- docs/decisions/17670-bidi-is-an-implementation-mechanism.md[81-87]

### Suggested change
1. Add a `## Binding status` section at the end, using the template’s table columns (`Binding | Status | Notes / tracking link`).
2. Optionally repurpose the existing “Current behavior” details into the Notes column.
3. Replace the Consequences bullet that points to “linked from this record’s PR” with an explicit link in the table (or in Consequences) so the record remains self-contained.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

3. ~~Option 3 ambiguous~~ ✓ Resolved 🐞 Bug ≡ Correctness

Description

In ADR 0001, considered option #3 lacks an explicit Accepted/Rejected marker and its explanation
reads like the rationale for the *opposite* choice (hiding BiDi from users), leaving the decision
record unclear about what was rejected and why. This makes the ADR less self-contained and increases
the risk of misinterpreting the intended cross-binding direction.

Code

docs/decisions/0001-bidi-is-an-implementation-mechanism.md[R38-40]

+3. Allow methods and classes to reference BiDi
+   * users shouldn't need to know the underlying implementation mechanism, things should just work without additional ceremony
+4. Internal implementation mechanism only (Accepted)

Evidence
Option #3 is missing an Accepted/Rejected label and its supporting bullet reads like an argument for
hiding the implementation mechanism, while the ADR template expects options to state why they were
accepted or rejected.
docs/decisions/0001-bidi-is-an-implementation-mechanism.md[38-40]
docs/decisions/0000-template.md[23-26]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
ADR 0001’s “Considered options” list contains an option (#3) that does not indicate whether it was accepted or rejected, and its rationale text appears to argue for the internal-only approach rather than for allowing BiDi references. This ambiguity reduces the ADR’s usefulness as a durable record.

## Issue Context
The ADR template expects each considered option to state why it was accepted or rejected; the current option #3 neither labels its status nor clearly explains why it lost relative to option #4.

## Fix Focus Areas
- docs/decisions/0001-bidi-is-an-implementation-mechanism.md[38-40]

## Suggested fix
- Mark option #3 explicitly as `(Rejected)`.
- Rewrite its bullet to explain *why* allowing public API surfaces to reference BiDi was rejected (e.g., it exposes protocol details, couples the supported API to an implementation mechanism, harms portability/compatibility), and ensure it no longer reads like support for option #4.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

View more (1)

4. ~~Discussion link not PR~~ ✓ Resolved 🐞 Bug ⚙ Maintainability

Description

ADR 0001’s “Discussion” field uses “PR pending” and links to an issue instead of linking to the
ADR’s PR, which conflicts with the template/process that defines the PR thread as the discussion
record. This weakens traceability from the ADR to its canonical review/discussion history.

Code

docs/decisions/0001-bidi-is-an-implementation-mechanism.md[5]
+- Discussion: _PR pending_, https://github.com/SeleniumHQ/selenium/issues/17628

Evidence
The template explicitly instructs Discussion to link to the record’s PR, and the README states the
PR thread is the discussion record; ADR 0001 currently does not provide that PR link.
docs/decisions/0001-bidi-is-an-implementation-mechanism.md[3-6]
docs/decisions/0000-template.md[6-9]
docs/decisions/README.md[30-36]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
The ADR template/process expects the `Discussion:` field to link to the decision record’s PR (the canonical discussion record). ADR 0001 currently says `_PR pending_` and links to an issue instead.

### Issue Context
It’s fine to reference related issues, but per the template those should go under **Context** (or otherwise be secondary), while `Discussion:` should point at the ADR PR.

### Fix Focus Areas
- docs/decisions/0001-bidi-is-an-implementation-mechanism.md[3-6]
- docs/decisions/0000-template.md[6-9]
- docs/decisions/README.md[30-36]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

5. Hidden ADR index 🐞 Bug ⚙ Maintainability

Description

The ADR index is introduced as a dotfile (docs/decisions/.index.md) and is not referenced from
docs/decisions/README.md, so readers who follow the documented ADR entry point won’t discover the
index page. This reduces ADR discoverability and makes it harder to navigate the decisions log over
time.

Code

docs/decisions/.index.md[R1-3]

+# Index of Decisions
+
+* 0001 - BiDi is an implementation mechanism, not a public API

Evidence

The new index file exists but is not referenced by the ADR directory’s main README/process doc, so
navigation to the index is not discoverable from the documented entry point.

docs/decisions/.index.md[1-3]
docs/decisions/README.md[1-45]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The ADR index is stored in `docs/decisions/.index.md` but `docs/decisions/README.md` does not link to it, so readers landing on the ADR directory documentation won't find the index.

## Issue Context
The ADR process documentation lives in `docs/decisions/README.md`, which serves as the primary entry point for how to use/consume ADRs in this repo.

## Fix Focus Areas
- docs/decisions/README.md[1-45]
- docs/decisions/.index.md[1-3]

## Suggested fix
Do one of the following:
1. Add a prominent link to `.index.md` near the top of `README.md` (e.g., “Index of Decisions”).
2. Rename `.index.md` to `index.md` or `INDEX.md` and link to it from `README.md`.
3. Alternatively, merge the index list into `README.md` and drop the separate index file.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

6. ~~Untracked items claim~~ ✓ Resolved 🐞 Bug ⚙ Maintainability

Description

ADR 0001 says non-conforming public surfaces are “tracked below”, but the Binding status table
provides no notes/tracking links for any binding, so the ADR doesn’t actually provide the promised
tracking references.

Code

docs/decisions/0001-bidi-is-an-implementation-mechanism.md[R44-56]

+- Users never need to know which protocol services a command.
+- Each new capability requires API design work across bindings before it ships.
+- Existing public surfaces that fail the conformance tests are brought in line per the deprecation policy, tracked below.
+
+## Binding status
+
+| Binding    | Status  | Notes / tracking link |
+|------------|---------|-----------------------|
+| Java       | pending |                       |
+| Python     | pending |                       |
+| Ruby       | pending |                       |
+| .NET       | pending |                       |
+| JavaScript | pending |                       |

Evidence
The ADR explicitly claims tracking exists “below”, but the subsequent binding-status table leaves
the tracking column empty for every binding; the decision template indicates that column is intended
to carry “Notes / tracking link” information.
docs/decisions/0001-bidi-is-an-implementation-mechanism.md[44-56]
docs/decisions/0000-template.md[39-50]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The ADR states that non-conforming public surfaces are “tracked below”, but the Binding status table has an empty “Notes / tracking link” column across all bindings, so there is no actual tracking information.

## Issue Context
This is a documentation consistency/traceability problem inside the ADR itself.

## Fix Focus Areas
- docs/decisions/0001-bidi-is-an-implementation-mechanism.md[44-56]

## Expected change
Either:
1) Populate the “Notes / tracking link” cells with the relevant tracking issues/PRs per binding, or
2) Remove/adjust the “tracked below” wording until concrete tracking links exist.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

7. Index entry not linked 🐞 Bug ⚙ Maintainability

Description

docs/decisions/.index.md lists ADR 0001 as plain text instead of a markdown link, so the “Index of
Decisions” is not navigable. Readers can’t click through to the actual record file.

Code

docs/decisions/.index.md[3]
+* 0001 - BiDi is an implementation mechanism, not a public API

Evidence
The index contains only plain text for ADR 0001, while the actual record lives in a separate slugged
markdown file; without a link the index doesn’t provide navigation.
docs/decisions/.index.md[1-3]
docs/decisions/0001-bidi-is-an-implementation-mechanism.md[1-2]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`docs/decisions/.index.md` is intended to be an index, but the ADR entry is plain text rather than a markdown link to the decision record file, which makes the index non-navigable.

### Issue Context
The ADR itself is stored in a slugged filename (`0001-bidi-is-an-implementation-mechanism.md`), so a link also removes ambiguity about the destination.

### Fix Focus Areas
- docs/decisions/.index.md[1-3]
- docs/decisions/0001-bidi-is-an-implementation-mechanism.md[1-2]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Previous review results

Review updated until commit cdc95ab

Results up to commit f32ab0f

🐞 Bugs (1) 📘 Rule violations (0) 📎 Requirement gaps (0) 🎨 UX issues (0) 🔗 Cross-repo conflicts (0) 📜 Skill insights (0)

1. ~~Discussion link not PR~~ ✓ Resolved 🐞 Bug ⚙ Maintainability

Description

ADR 0001’s “Discussion” field uses “PR pending” and links to an issue instead of linking to the
ADR’s PR, which conflicts with the template/process that defines the PR thread as the discussion
record. This weakens traceability from the ADR to its canonical review/discussion history.

Code

docs/decisions/0001-bidi-is-an-implementation-mechanism.md[5]
+- Discussion: _PR pending_, https://github.com/SeleniumHQ/selenium/issues/17628

Evidence
The template explicitly instructs Discussion to link to the record’s PR, and the README states the
PR thread is the discussion record; ADR 0001 currently does not provide that PR link.
docs/decisions/0001-bidi-is-an-implementation-mechanism.md[3-6]
docs/decisions/0000-template.md[6-9]
docs/decisions/README.md[30-36]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
The ADR template/process expects the `Discussion:` field to link to the decision record’s PR (the canonical discussion record). ADR 0001 currently says `_PR pending_` and links to an issue instead.

### Issue Context
It’s fine to reference related issues, but per the template those should go under **Context** (or otherwise be secondary), while `Discussion:` should point at the ADR PR.

### Fix Focus Areas
- docs/decisions/0001-bidi-is-an-implementation-mechanism.md[3-6]
- docs/decisions/0000-template.md[6-9]
- docs/decisions/README.md[30-36]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

2. Index entry not linked 🐞 Bug ⚙ Maintainability

Description

docs/decisions/.index.md lists ADR 0001 as plain text instead of a markdown link, so the “Index of
Decisions” is not navigable. Readers can’t click through to the actual record file.

Code

docs/decisions/.index.md[3]
+* 0001 - BiDi is an implementation mechanism, not a public API

Evidence
The index contains only plain text for ADR 0001, while the actual record lives in a separate slugged
markdown file; without a link the index doesn’t provide navigation.
docs/decisions/.index.md[1-3]
docs/decisions/0001-bidi-is-an-implementation-mechanism.md[1-2]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`docs/decisions/.index.md` is intended to be an index, but the ADR entry is plain text rather than a markdown link to the decision record file, which makes the index non-navigable.

### Issue Context
The ADR itself is stored in a slugged filename (`0001-bidi-is-an-implementation-mechanism.md`), so a link also removes ambiguity about the destination.

### Fix Focus Areas
- docs/decisions/.index.md[1-3]
- docs/decisions/0001-bidi-is-an-implementation-mechanism.md[1-2]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Results up to commit 3d21495

🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0) 🎨 UX issues (0) 🔗 Cross-repo conflicts (0) 📜 Skill insights (0)

1. ~~Option 3 ambiguous~~ ✓ Resolved 🐞 Bug ≡ Correctness

Description

In ADR 0001, considered option #3 lacks an explicit Accepted/Rejected marker and its explanation
reads like the rationale for the *opposite* choice (hiding BiDi from users), leaving the decision
record unclear about what was rejected and why. This makes the ADR less self-contained and increases
the risk of misinterpreting the intended cross-binding direction.

Code

docs/decisions/0001-bidi-is-an-implementation-mechanism.md[R38-40]

+3. Allow methods and classes to reference BiDi
+   * users shouldn't need to know the underlying implementation mechanism, things should just work without additional ceremony
+4. Internal implementation mechanism only (Accepted)

Evidence
Option #3 is missing an Accepted/Rejected label and its supporting bullet reads like an argument for
hiding the implementation mechanism, while the ADR template expects options to state why they were
accepted or rejected.
docs/decisions/0001-bidi-is-an-implementation-mechanism.md[38-40]
docs/decisions/0000-template.md[23-26]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
ADR 0001’s “Considered options” list contains an option (#3) that does not indicate whether it was accepted or rejected, and its rationale text appears to argue for the internal-only approach rather than for allowing BiDi references. This ambiguity reduces the ADR’s usefulness as a durable record.

## Issue Context
The ADR template expects each considered option to state why it was accepted or rejected; the current option #3 neither labels its status nor clearly explains why it lost relative to option #4.

## Fix Focus Areas
- docs/decisions/0001-bidi-is-an-implementation-mechanism.md[38-40]

## Suggested fix
- Mark option #3 explicitly as `(Rejected)`.
- Rewrite its bullet to explain *why* allowing public API surfaces to reference BiDi was rejected (e.g., it exposes protocol details, couples the supported API to an implementation mechanism, harms portability/compatibility), and ensure it no longer reads like support for option #4.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Results up to commit 7b86053

🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0) 🎨 UX issues (0) 🔗 Cross-repo conflicts (0) 📜 Skill insights (0)

1. ~~Untracked items claim~~ ✓ Resolved 🐞 Bug ⚙ Maintainability

Description

ADR 0001 says non-conforming public surfaces are “tracked below”, but the Binding status table
provides no notes/tracking links for any binding, so the ADR doesn’t actually provide the promised
tracking references.

Code

docs/decisions/0001-bidi-is-an-implementation-mechanism.md[R44-56]

+- Users never need to know which protocol services a command.
+- Each new capability requires API design work across bindings before it ships.
+- Existing public surfaces that fail the conformance tests are brought in line per the deprecation policy, tracked below.
+
+## Binding status
+
+| Binding    | Status  | Notes / tracking link |
+|------------|---------|-----------------------|
+| Java       | pending |                       |
+| Python     | pending |                       |
+| Ruby       | pending |                       |
+| .NET       | pending |                       |
+| JavaScript | pending |                       |

Evidence
The ADR explicitly claims tracking exists “below”, but the subsequent binding-status table leaves
the tracking column empty for every binding; the decision template indicates that column is intended
to carry “Notes / tracking link” information.
docs/decisions/0001-bidi-is-an-implementation-mechanism.md[44-56]
docs/decisions/0000-template.md[39-50]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The ADR states that non-conforming public surfaces are “tracked below”, but the Binding status table has an empty “Notes / tracking link” column across all bindings, so there is no actual tracking information.

## Issue Context
This is a documentation consistency/traceability problem inside the ADR itself.

## Fix Focus Areas
- docs/decisions/0001-bidi-is-an-implementation-mechanism.md[44-56]

## Expected change
Either:
1) Populate the “Notes / tracking link” cells with the relevant tracking issues/PRs per binding, or
2) Remove/adjust the “tracked below” wording until concrete tracking links exist.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Results up to commit d5fcb13

🐞 Bugs (1) 📘 Rule violations (0) 📎 Requirement gaps (0) 🎨 UX issues (0) 🔗 Cross-repo conflicts (0) 📜 Skill insights (0)

1. Hidden ADR index 🐞 Bug ⚙ Maintainability

Description

The ADR index is introduced as a dotfile (docs/decisions/.index.md) and is not referenced from
docs/decisions/README.md, so readers who follow the documented ADR entry point won’t discover the
index page. This reduces ADR discoverability and makes it harder to navigate the decisions log over
time.

Code

docs/decisions/.index.md[R1-3]

+# Index of Decisions
+
+* 0001 - BiDi is an implementation mechanism, not a public API

Evidence

The new index file exists but is not referenced by the ADR directory’s main README/process doc, so
navigation to the index is not discoverable from the documented entry point.

docs/decisions/.index.md[1-3]
docs/decisions/README.md[1-45]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The ADR index is stored in `docs/decisions/.index.md` but `docs/decisions/README.md` does not link to it, so readers landing on the ADR directory documentation won't find the index.

## Issue Context
The ADR process documentation lives in `docs/decisions/README.md`, which serves as the primary entry point for how to use/consume ADRs in this repo.

## Fix Focus Areas
- docs/decisions/README.md[1-45]
- docs/decisions/.index.md[1-3]

## Suggested fix
Do one of the following:
1. Add a prominent link to `.index.md` near the top of `README.md` (e.g., “Index of Decisions”).
2. Rename `.index.md` to `index.md` or `INDEX.md` and link to it from `README.md`.
3. Alternatively, merge the index list into `README.md` and drop the separate index file.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

qodo-code-review · 2026-06-11T13:44:28Z

PR Summary by Qodo

Add ADR process docs and record BiDi as internal implementation detail
📝 Documentation 🕐 10-20 Minutes

Walkthroughs

Description

• Add an ADR/decision-record process, template, and approval rules under docs/decisions.
• Record the decision that BiDi is internal and must not appear in supported public APIs.
• Add a decisions index to make adopted proposals discoverable and citable.

Diagram

graph TD
  A([Contributor]) --> F[["docs/decisions/"]] --> B["ADR template"] --> C["BiDi ADR 0001"] --> D["Index"] --> E["Process README"]

  subgraph Legend
    direction LR
    _p([Person]) ~~~ _dir[["Directory"]] ~~~ _doc["Document"]
  end

High-Level Assessment

The following are alternative approaches to this PR:

1. Use GitHub Discussions/Issues as the canonical decision log

➕ No new docs structure to maintain
➕ Discussion context and decision live together in one place
➕ Searchable and linkable with existing GitHub tooling
➖ Harder to keep a stable, curated, single-source-of-truth record
➖ More difficult to enforce immutability rules (superseding vs editing)
➖ Less friendly for offline/docs-site consumption

2. Adopt an ADR tool/convention (e.g., adr-tools) with CLI automation

➕ Standardized workflows (create/supersede/index) reduce process drift
➕ Consistent naming/metadata via automation
➖ Adds tooling overhead and cross-platform considerations
➖ May not fit Selenium’s multi-repo/multi-binding governance model
➖ Still requires human review for content correctness

Recommendation: The current approach (plain Markdown ADRs with a lightweight documented process and a simple index) is the best fit here: it keeps the decision record close to the codebase, is language/tool neutral, and is easy for all binding maintainers to follow without introducing new tooling dependencies.

File Changes

Documentation (4)

.index.md Add decisions index entry for ADR 0001 +3/-0
Add decisions index entry for ADR 0001
• Introduces an index page for the decisions directory. Adds a first entry pointing to decision 0001 for discoverability.
docs/decisions/.index.md

0000-template.md Add ADR template with required sections and binding status table +56/-0
Add ADR template with required sections and binding status table
• Adds a standardized decision record template covering context, decision, options, consequences, and per-binding status tracking. Includes guidance on writing, mutability, and what belongs in the record vs the PR thread.
docs/decisions/0000-template.md

0001-bidi-is-an-implementation-mechanism.md Add ADR 0001 defining BiDi as internal, not a supported public API +49/-0
Add ADR 0001 defining BiDi as internal, not a supported public API
• Records the project-wide decision that BiDi is an implementation mechanism and must not appear in supported API surfaces. Defines conformance criteria and documents rejected alternatives and consequences.
docs/decisions/0001-bidi-is-an-implementation-mechanism.md

README.md Document ADR scope, process, approval rules, and immutability constraints +71/-0
Document ADR scope, process, approval rules, and immutability constraints
• Adds the decision-log charter for cross-binding semantics, including what requires a record and the proposal/discussion/acceptance workflow. Defines TLC review expectations and rules for superseding decisions and numbering stability.
docs/decisions/README.md

qodo-code-review · 2026-06-11T15:47:57Z

Code review by qodo was updated up to the latest commit 3d21495

qodo-code-review · 2026-06-19T13:49:18Z

Code review by qodo was updated up to the latest commit 7b86053

diemol

💯% agreeing with this.

qodo-code-review · 2026-06-19T15:56:19Z

Code review by qodo was updated up to the latest commit d5fcb13

… examples

qodo-code-review · 2026-06-23T21:55:23Z

Code review by qodo was updated up to the latest commit cdc95ab

pujagani · 2026-06-25T07:58:34Z

I agree with the rationale explained in this ADR.

diemol

We decided in the TLC meeting that Titus will detail a bit more what conceptually means to have the BiDi code as internal and then we can move to approve this ADR.

titusfortner added 2 commits June 11, 2026 08:34

[docs] add design decision record process and template

9288155

[adr] BiDi is an implementation mechanism, not a public API

f32ab0f

titusfortner added the A-needs decision TLC needs to discuss and agree label Jun 11, 2026

add examples with details as requested

3d21495

nvborisenko reviewed Jun 17, 2026

View reviewed changes

Comment thread docs/decisions/0001-bidi-is-an-implementation-mechanism.md Outdated

Merge branch 'trunk' into adr1

7b86053

diemol approved these changes Jun 19, 2026

View reviewed changes

Merge branch 'trunk' into adr1

d5fcb13

This was referenced Jun 21, 2026

[adr] BiDi low-level definitions are generated from a shared spec model without orchestration #17701

Open

[adr] Java CDDL generator proposal #17692

Closed

[adr] rework BiDi record: number by PR, drop index, reframe table and…

cdc95ab

… examples

pujagani approved these changes Jun 25, 2026

View reviewed changes

This was referenced Jun 25, 2026

[docs] Selenium 5 release charter #17717

Open

[docs] decision: BiDi is exposed in three API layers #17709

Open

diemol reviewed Jul 2, 2026

View reviewed changes

pujagani mentioned this pull request Jul 3, 2026

[java] Prevent accessing BiDi internals from driver #17745

Closed

3 tasks

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Uh oh!

[adr] BiDi is an implementation mechanism, not a public API#17670

[adr] BiDi is an implementation mechanism, not a public API#17670
titusfortner wants to merge 6 commits into
SeleniumHQ:trunkfrom
titusfortner:adr1

titusfortner commented Jun 11, 2026 •

edited

Loading

Uh oh!

qodo-code-review Bot commented Jun 11, 2026 •

edited

Loading

Uh oh!

qodo-code-review Bot commented Jun 11, 2026

Uh oh!

qodo-code-review Bot commented Jun 11, 2026 •

edited

Loading

Uh oh!

Uh oh!

qodo-code-review Bot commented Jun 19, 2026

Uh oh!

diemol left a comment

Uh oh!

qodo-code-review Bot commented Jun 19, 2026

Uh oh!

qodo-code-review Bot commented Jun 23, 2026

Uh oh!

pujagani commented Jun 25, 2026

Uh oh!

diemol left a comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Uh oh!

Uh oh!

Conversation

titusfortner commented Jun 11, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

🔗 Related

📝 Proposal notes

🗣 Discussion

📌 Tracking

Uh oh!

qodo-code-review Bot commented Jun 11, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Code Review by Qodo

Previous review results

Uh oh!

qodo-code-review Bot commented Jun 11, 2026

PR Summary by Qodo

Walkthroughs

File Changes

Uh oh!

qodo-code-review Bot commented Jun 11, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

qodo-code-review Bot commented Jun 19, 2026

Uh oh!

diemol left a comment

Choose a reason for hiding this comment

Uh oh!

qodo-code-review Bot commented Jun 19, 2026

Uh oh!

qodo-code-review Bot commented Jun 23, 2026

Uh oh!

pujagani commented Jun 25, 2026

Uh oh!

diemol left a comment

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

titusfortner commented Jun 11, 2026 •

edited

Loading

qodo-code-review Bot commented Jun 11, 2026 •

edited

Loading

qodo-code-review Bot commented Jun 11, 2026 •

edited

Loading