docs: reflect splent_framework 1.7.1

The framework now drives the Selenium Grid itself and discovers every
feature's locustfile, so the pages describing it as incapable of either,
and tests/selenium_support.py as a temporary replacement, were out of
date the moment 1.7.1 shipped.

The selenium sections now document SELENIUM_GRID_URL, SELENIUM_TARGET_URL
and SELENIUM_BROWSER, and describe the local module as what it became: a
thin wrapper that defaults those variables to this stack's container names
and pins the viewport. The load-testing page drops the note explaining why
Rosemary had to resolve locustfiles itself, because it no longer does: the
whole-project run defers to the framework bootstrap, and
SPLENT_LOCUSTFILES is documented for products that keep load tests
elsewhere. Version pins move to 1.7.1.

Author: drorganvidez

architecture/project_structure.md

@@ -101,11 +101,11 @@ Fixtures that only concern one feature belong in `app/features/<feature>/tests/c
 
 ## tests
 
-Cross-feature test support that does not belong to any single feature. It currently holds `selenium_support.py`, the helper that resolves the WebDriver and the target host for the end-to-end layer.
+Cross-feature test support that does not belong to any single feature. It currently holds `selenium_support.py`, the e2e layer's single import point for the WebDriver and the target host.
 
-Both helpers branch on `WORKING_DIR`. Inside Docker (`WORKING_DIR=/workspace/`), `selenium_support.initialize_driver()` returns a `webdriver.Remote` attached to the Selenium Grid started by `docker/docker-compose.dev.yml`, and `get_host_for_selenium_testing()` returns the URL of the app *as the browser sees it* — the nginx container, not `localhost`, because `localhost` inside the browser container resolves to the browser itself. Run outside Docker, `initialize_driver()` falls back to a local `webdriver.Chrome()` or `webdriver.Firefox()` and the host becomes `http://localhost:5000`.
+Since `splent_framework` 1.7.1 the driver itself comes from the framework, which attaches to the Selenium Grid named by `SELENIUM_GRID_URL` and honours `SELENIUM_TARGET_URL` for the URL the browser opens — the nginx container, not `localhost`, because `localhost` inside the browser container resolves to the browser itself. The wrapper defaults both variables to this stack's container names when running under Docker, and pins a 1920x1080 window so both grid browsers see the same responsive layout. Run outside Docker, neither variable is defaulted and the framework launches a local browser against `http://localhost:5000`.
 
-This module exists because the framework's own Selenium helper builds a local Chrome through `webdriver_manager`, and no browser is installed inside `web_app_container`. Every `test_selenium.py` in the project imports from here:
+Every `test_selenium.py` in the project imports from here:
 
 ```python
 from tests.selenium_support import close_driver, get_host_for_selenium_testing, initialize_driver
@@ -217,7 +217,7 @@ A list of files and directories that Git should ignore. This prevents certain fi
 The pinned list of Python dependencies, installed with `pip`. Every version is pinned exactly. The entry that matters most to the architecture is the framework the product is built on:
 
 ```
-splent_framework==1.7.0
+splent_framework==1.7.1
 ```
 
 See [splent_framework]({{site.baseurl}}/architecture/splent_framework) for what that package provides.

architecture/splent_framework.md

@@ -23,7 +23,7 @@ nav_order: 4
 The framework is a normal pinned dependency in `requirements.txt`:
 
 ```
-splent_framework==1.7.0
+splent_framework==1.7.1
 ```
 
 Installing the project's dependencies installs it:
@@ -205,23 +205,21 @@ The four fixtures differ in how aggressively they reset the database. `test_clie
 
 ## Things to know
 
-Two parts of the framework do not cover what {% include uvlhub.html %} needs, and the repository works around both. Reaching for the framework helper in these places will not work, so it is worth knowing where the seams are.
+A few framework behaviours are worth knowing before you reach for them, because they shape how this repository is wired.
 
 ### Selenium
 
-The end-to-end layer is driven by the repository-local helper `tests/selenium_support.py`, not by `splent_framework.selenium.common`:
+Since 1.7.1 the framework itself can drive a Selenium Grid. `initialize_driver` attaches to the hub named by `SELENIUM_GRID_URL` through `webdriver.Remote`, so the browser runs in a grid node container; without that variable it launches a local browser through `webdriver_manager`, as before. It accepts chrome (the default) and firefox, chosen per call or through `SELENIUM_BROWSER`, and `get_host_for_selenium_testing` honours `SELENIUM_TARGET_URL` — needed because the URL a test opens is resolved *by the browser*, and inside a grid node `localhost` is the node itself.
+
+The e2e layer still imports from the repository-local `tests/selenium_support.py`:
 
 ```python
 from tests.selenium_support import close_driver, get_host_for_selenium_testing, initialize_driver
 ```
 
-The framework's `initialize_driver` builds a *local* Chrome through `webdriver_manager`, and no browser is installed inside `web_app_container`, so every e2e test would fail before reaching the app. It also takes no arguments, so there is no way to ask it for Firefox. When `WORKING_DIR` is `/workspace/`, the local helper instead returns a `webdriver.Remote` attached to the Selenium Grid that `docker/docker-compose.dev.yml` starts, so the browser runs in the `selenium_chrome_container` or `selenium_firefox_container`. Outside Docker it builds a local browser, as the framework does.
-
-The browser choice travels by environment variable. `rosemary selenium --driver firefox` sets `SELENIUM_BROWSER`, which `initialize_driver` reads. Earlier versions of that command tried to call a `set_service_driver` helper on `splent_framework.selenium.common`; no such function exists, so do not reintroduce that call.
-
-The host differs too. The framework's `get_host_for_selenium_testing` returns `http://localhost` under `/workspace/`, but the host name is resolved *by the browser*, and inside the browser container `localhost` is the browser itself. The local helper returns the nginx container URL instead. `get_host_for_locust_testing` already gets this right, which is why the load tests do import it from the framework.
+but that module is now a thin wrapper over the framework helpers. It defaults `SELENIUM_GRID_URL` and `SELENIUM_TARGET_URL` to this stack's container names when running under Docker, and pins a 1920x1080 window so the responsive layout is identical whichever browser the grid hands out. The driver itself comes from the framework.
 
-Both differences are recorded in the docstring of `tests/selenium_support.py`. If the framework grows grid support, the local helper can be dropped.
+The browser choice travels by environment variable: `rosemary selenium --driver firefox` sets `SELENIUM_BROWSER`, which the framework reads.
 
 ### Feature assets
 

rosemary_cli/testing/gui_tests.md

@@ -62,30 +62,29 @@ run and what makes `--e2e` able to select them.
 
 ## The driver helpers
 
-The imports come from `tests/selenium_support.py`, a repo-local module, not from
-`splent_framework`. Read that file's docstring for the full reasoning; the short version is that
-the framework's `selenium.common` cannot drive the grid:
+The imports come from `tests/selenium_support.py`, which since `splent_framework` 1.7.1 is a thin
+wrapper over the framework's own helpers. The framework drives the grid natively: when
+`SELENIUM_GRID_URL` is set, `initialize_driver` attaches to that hub through `webdriver.Remote`, so
+the browser runs in the `selenium-chrome` or `selenium-firefox` container; without it, a local
+browser is launched through `webdriver_manager`. `get_host_for_selenium_testing` honours
+`SELENIUM_TARGET_URL`, which matters because the URL is resolved **by the browser**, and inside a
+grid node `localhost` is the node itself.
 
-- its `initialize_driver` builds a **local** Chrome through `webdriver_manager`, and there is no
-  browser installed inside `web_app_container`, so every test raises before it reaches the app;
-- its `get_host_for_selenium_testing` returns `localhost`, but the host is resolved **by the
-  browser**, and inside the browser container `localhost` is the browser itself.
-
-`tests/selenium_support.py` fixes both. It builds a `webdriver.Remote` pointed at the grid so the
-browser runs in the `selenium-chrome` or `selenium-firefox` container, and it targets the nginx
-container rather than `localhost`:
+What the wrapper adds on top:
 
 ```python
-GRID_URL = os.getenv("SELENIUM_GRID_URL", "http://selenium_hub_container:4444")
-DOCKER_HOST_URL = os.getenv("SELENIUM_TARGET_URL", "http://nginx_web_server_container")
-LOCAL_HOST_URL = "http://localhost:5000"
+if os.getenv("WORKING_DIR", "") == "/workspace/":
+    os.environ.setdefault("SELENIUM_GRID_URL", "http://selenium_hub_container:4444")
+    os.environ.setdefault("SELENIUM_TARGET_URL", "http://nginx_web_server_container")
 ```
 
-Outside Docker the same helper falls back to a local `webdriver.Firefox()` or `webdriver.Chrome()`
-and to `http://localhost:5000`, so the identical test file works in both environments.
+so the grid and the target default to this stack's container names under Docker, plus a pinned
+1920x1080 window. Browser defaults differ (chrome nodes open at about 945px, firefox at about
+1280px), and below the responsive breakpoint the sidebar collapses off-canvas, so an unpinned
+viewport makes the same test pass on one browser and fail on the other.
 
-This module is meant to be temporary. Drop it and go back to the framework helpers once
-`splent_framework` grows grid support.
+Outside Docker neither variable is defaulted, so the framework launches a local browser against
+`http://localhost:5000` and the identical test file works in both environments.
 
 ---
 

rosemary_cli/testing/load_tests.md

@@ -151,25 +151,16 @@ and picks up `WORKING_DIR` from the environment already there.
 rosemary locust
 ```
 
-With no argument, every feature that has a `locustfile.py` is loaded at once. Locust accepts a
-comma-separated list, so Rosemary collects the files under `app/features/*/tests/locustfile.py` and
-passes them together. The web interface then lets you pick which user classes to run, or swarm all of
-them.
-
-{: .note-title }
-> Why Rosemary resolves the list itself
->
-> It would be natural to defer to the default bootstrap that ships with `splent_framework`, and
-> Rosemary used to. That bootstrap has not followed the `app/features/` rename: version 1.7.0 still globs
-> `app/modules/*/tests/locustfile.py`, a directory this repository no longer has, so it collected zero
-> `HttpUser` classes and raised `ValueError: No User class found!` at import time, before Locust
-> started. You can still see it fail on its own:
->
-> ```bash
-> docker exec web_app_container python -c "from splent_framework.bootstraps import locustfile_bootstrap"
-> ```
->
-> Resolving the paths in Rosemary sidesteps it until the framework catches up.
+With no argument, every feature that has a `locustfile.py` is loaded at once. Discovery is done by
+`splent_framework`'s locustfile bootstrap, which since 1.7.1 finds
+`app/features/*/tests/locustfile.py` on its own: in Docker, Rosemary simply omits `-f` and the
+locust entrypoint resolves the bootstrap from site-packages; outside Docker, Rosemary points locust
+at the bootstrap module directly. The web interface then lets you pick which user classes to run, or
+swarm all of them. Loaded class names carry a per-feature suffix, `AuthUser_splent_locustfile_auth`
+for example, so two features' classes can never shadow each other.
+
+To load from somewhere else entirely, set `SPLENT_LOCUSTFILES` to a comma-separated list of glob
+patterns, relative to `WORKING_DIR` unless absolute.
 
 ## How it runs per environment