Merge branch 'trunk' into fix-python-options-snippets-2621

Author: rpallavisharma

.github/copilot-instructions.md

@@ -0,0 +1 @@
+When reviewing a pull request, also follow the guidelines in .github/pr_review.md.

.github/pr_review.md

@@ -0,0 +1,48 @@
+# PR Review Guidelines
+
+Use these guidelines when reviewing pull requests for this documentation repository.
+
+## Priorities
+
+- First look for changes that can break rendered documentation: malformed Markdown, Hugo
+  shortcodes, `tabpane` / `tab` pairs, code fences, front matter, anchors, or translated page
+  structure. Small whitespace and delimiter changes can break code blocks or entire sections.
+- Treat `gh-codeblock` paths and line ranges as correctness-sensitive. If `examples/` changed,
+  search `website_and_docs/content` for references to the changed files. If docs changed a
+  `gh-codeblock`, verify the path still exists and the line range shows exactly the intended
+  snippet.
+- Check translation maintenance against `website_and_docs/content/documentation/about/style.en.md`.
+  English text changes do not require translated files in the same PR, but changed translation
+  files must preserve working front matter, shortcodes, tabs, code blocks, and example references.
+  When the style guide requires translated code examples, verify the matching translated files were
+  updated.
+- For examples, review code correctness only as it affects the published docs: runnable snippets,
+  assertions where practical, stable demo pages, and matching documentation references.
+
+## Documentation checks
+
+- Front matter should match the surrounding page style.
+- `linkTitle` should be short and title-cased; `title` should use sentence case.
+- General prose should be language-independent. Put binding-specific code or behavior in language
+  tabs.
+- When all tabs use `gh-codeblock`, the `tabpane` should use `text=true`. When only some tabs use
+  shortcodes or markdown, those tabs need `text=true`.
+- `gh-codeblock` lines must not be indented. Plain text in markdown tabs also must not be
+  accidentally indented into a code block.
+
+## Do not comment on
+
+- Missing translated files for ordinary English text changes.
+- Subjective wording preferences unless the text is inaccurate, confusing, or inconsistent with
+  the Selenium docs style guide.
+- Formatting nits that do not affect rendering, code block structure, shortcode parsing, or
+  maintainability.
+- CI status without a clear connection to the diff.
+
+## Review style
+
+- Label severity as blocking, important, or minor.
+- Make each comment actionable: state the risk, why it matters, and the smallest fix.
+- Include file and line context when possible.
+- Do not leave duplicate comments for the same root cause.
+- It is acceptable to report no findings.

.gitignore

@@ -2,6 +2,37 @@
 public/
 node_modules
 .DS_Store
+
+/.local/*
+!/.local/README.md
+
+# Agent-specific local instruction overrides (keep private, never commit)
+AGENTS.local.md
+CLAUDE.local.md
+GEMINI.local.md
+
+# Security
+.env
+.env.local
+
+# AI agent local state (most common)
+/.claude
+/.cursor
+/.continue
+/.cline
+/.windsurf
+/.zencoder
+
+# Common per-tool config/rules files people accidentally add
+/.cursorignore
+/.cursorrules
+/.windsurfrules
+/.continuerc.json
+
+# Common generated transcripts
+*_cline_transcript.json
+.copilot-chat-history.json
+
 website_and_docs/.hugo_build.lock
 website_and_docs/resources
 *.png

.local/README.md

@@ -0,0 +1,17 @@
+# Local-only workspace
+
+This directory is for repo-local private work that should not be committed:
+
+- personal agent instructions, preferably `.local/AGENTS.md`;
+- personal agent skills under `.local/agent/skills/local-*`;
+- scratch code;
+- private experiments;
+- local helper scripts;
+- generated outputs;
+- temporary notes and prompts.
+
+Everything in this directory is ignored by Git except this README.
+
+Do not make production code, tests, CI, release tooling, or public documentation depend on files
+in this directory. If a local experiment becomes useful to the project, move it into a tracked
+source, test, docs, example, or scripts directory and review it normally.

.pr_agent.toml

@@ -0,0 +1,12 @@
+[pr_reviewer]
+extra_instructions = "Please look at the guidelines in .github/pr_review.md when evaluating this PR."
+
+[github_app]
+pr_commands = [
+    "/agentic_describe",
+    "/agentic_review",
+]
+handle_push_trigger = true
+push_commands = [
+    "/agentic_review",
+]

AGENTS.md

@@ -0,0 +1,65 @@
+# AGENTS.md
+
+## Project overview
+
+- Purpose: official Selenium website and documentation, built with Hugo and Docsy.
+- Primary content: Markdown, HTML, Hugo templates, site assets, structured data, and runnable
+  examples in Java, Python, .NET, Ruby, JavaScript, and Kotlin.
+- Setup and installation details live in `README.md`. Use its Quick start section for the current
+  Hugo Extended version, Docsy requirements, and local setup guidance.
+
+## Local contributor customization
+
+- The `.local/` directory is available for customization, generated artifacts, scratch work,
+  and temporary files. It is ignored by Git except for `.local/README.md`.
+- A contributor may create `.local/AGENTS.md` for personal repo-specific instructions and
+  preferences. Before beginning any task, check whether `.local/AGENTS.md` exists; if it
+  exists, read it with your file-reading tool and apply it as the contributor's local
+  instruction overlay.
+- If `.local/agent/skills/` exists, inspect its `*/SKILL.md` files and treat them as
+  additional user-defined skills.
+
+## Repository map
+
+- `website_and_docs/`: Hugo site root. Run local Hugo commands from here.
+- `website_and_docs/content/`: Published site content, including docs, blog posts, project pages,
+  and translations.
+- `website_and_docs/content/documentation/`: Main Selenium documentation. Read
+  `about/style.en.md` for documentation style conventions before editing docs.
+- `website_and_docs/layouts/`: Hugo templates and shortcodes.
+- `website_and_docs/assets/`, `website_and_docs/static/`, `website_and_docs/data/`: Site assets,
+  static files, and structured data.
+- `examples/`: Runnable examples referenced from docs through `gh-codeblock`.
+- `scripts/`, `build-site.sh`, `netlify.toml`: Build, preview, release, and deploy support.
+- `website_and_docs/public/`, `website_and_docs/resources/`: Generated Hugo output/cache; avoid
+  manual edits.
+
+## Standard commands
+
+- Preview site locally: `cd website_and_docs && hugo server`
+- Preview without Hugo cache: `cd website_and_docs && hugo server --ignoreCache`
+- Build site like CI: `./build-site.sh`
+- Java examples: `cd examples/java && mvn test`
+- Python examples: `cd examples/python && pytest`
+- JavaScript examples: `cd examples/javascript && npm test`
+- Ruby examples: `cd examples/ruby && bundle exec rspec`
+- Ruby example lint: `cd examples/ruby && bundle exec rubocop`
+- .NET examples: `cd examples/dotnet/SeleniumDocs && dotnet test`
+- Kotlin examples: `cd examples/kotlin && mvn test`
+
+## Working guidance
+
+- Prefer small, focused changes that match the existing structure and naming.
+- Follow `website_and_docs/content/documentation/about/style.en.md` for docs style. In particular,
+  keep prose language-independent, put binding-specific code in tabs, use `gh-codeblock` for
+  runnable snippets, and do not indent `gh-codeblock` lines.
+- Changes under `examples/` probably require matching markdown updates. Search
+  `website_and_docs/content` for affected `gh-codeblock` paths and update line ranges after moving,
+  adding, or removing lines.
+- For docs/layout changes, run `./build-site.sh` when practical. For example changes, run the
+  relevant binding's example tests and check affected `gh-codeblock` references.
+- For PR review tasks, read `.github/pr_review.md` before reviewing.
+- GitHub Actions builds the site on PRs touching `website_and_docs/**`. Deploys occur from `trunk`
+  when a commit message contains `[deploy site]`; output is pushed to `publish`.
+- Never commit secrets, tokens, cookies, private keys, or local credentials. Tracked project files
+  must not depend on `.local/`.

CLAUDE.md

@@ -0,0 +1 @@
+This repository uses @AGENTS.md as the canonical repo instruction file.

website_and_docs/content/blog/2021/selenium-4-beta-1.md

@@ -43,7 +43,7 @@ By "**almost everything**", I mean that under the covers there have
 been substantial changes. We've rewritten the Selenium server to allow
 it to work not only in the familiar "standalone" and "hub and node"
 modes, but also in a new "distributed" mode, which makes it
-signifcantly easier to deploy to something such as Kubernetes in a way
+significantly easier to deploy to something such as Kubernetes in a way
 that scales well.
 
 The new server is also wired up with support for [OpenTelemetry][] and

website_and_docs/content/documentation/webdriver/elements/locators.en.md

@@ -380,9 +380,9 @@ and then a child element of that parent, you can instead combine those two `Find
 
 ### ByAll
 
-The `ByAll` class enables you to utilize two By locators at once, finding elements that mach _either_ of your By locators. 
+The `ByAll` class enables you to utilize two By locators at once, finding elements that match _either_ of your By locators. 
 For example, instead of having to utilize two `FindElement()` functions to find the username and password input fields 
-seperately, you can instead find them together in one clean `FindElements()`
+separately, you can instead find them together in one clean `FindElements()`
 
 {{< tabpane langEqualsHeader=true >}}
   {{< tab header="Java" text=true >}}

website_and_docs/content/documentation/webdriver/elements/locators.ja.md

@@ -371,8 +371,8 @@ functions into one.
 
 ### ByAll
 
-The `ByAll` class enables you to utilize two By locators at once, finding elements that mach _either_ of your By locators. 
-For example, instead of having to utilize two `FindElement()` functions to find the username and password input fields seperately, 
+The `ByAll` class enables you to utilize two By locators at once, finding elements that match _either_ of your By locators. 
+For example, instead of having to utilize two `FindElement()` functions to find the username and password input fields separately, 
 you can instead find them together in one clean `FindElements()`
 
 {{< tabpane langEqualsHeader=true >}}