@@ -1,17 +1,16 @@
 """Session fixtures for the OFREP conformance suite, and one recorded deviation.
 
-The container lifecycle belongs to the TCK: it starts the Compose file beside
-this module once per session, discovers the dynamically mapped host ports, builds
-the ``HttpControl`` against the launchpad and waits for it to accept commands.
-What is left here is the declaration, the one wrapper this provider needs around
-the control, and the xfail for the single scenario it cannot satisfy.
-
-The stack is started once and never restarted, because Compose assigns host
-ports dynamically and cannot preserve them across a restart: a restarted backend
-comes back on a different port, silently invalidating a provider already pointed
-at the old one, and the failure reads as a flaky provider rather than a broken
-test. Scenario isolation comes from the control API instead -- see the
-no-container-restart invariant in the TCK's ``control-api.yaml``.
+The container lifecycle belongs to the TCK -- see its README for what
+``tck_backend`` does with the declaration below, and Appendix F, "The control
+API", for why the stack is started once and never restarted. What is left here is
+the declaration, the one wrapper this provider needs around the control, and the
+xfail for the single scenario it cannot satisfy.
+
+A full run is ``2 failed, 45 passed, 17 skipped, 1 xfailed``. Both failures ask
+for ``large-integer-flag``, which flagd-testbed v3.8.0 does not seed --
+open-feature/flagd-testbed#392 adds it, along with the two other canonical flags
+the image is missing, and says what each catches. Neither carries a
+``KnownDeviation``: the gap is the backend's flag set, not the provider's.
 """
 
 from __future__ import annotations
@@ -24,22 +23,24 @@
 from tests.tck.settled_control import SettledControl
 
 OFREP_PORT = 8016
-"""flagd's OFREP HTTP port.
+"""flagd's OFREP HTTP port, and the one port this provider connects to.
 
-flagd's own default (``flags.Int32P("ofrep-port", "r", 8016, ...)`` in flagd's
-``cmd/start.go``). The testbed's launchpad starts flagd with no
-``--ofrep-port`` override, so this is what it listens on, and it is the one port
-the provider connects to. The launchpad's own 8080 is exposed automatically.
+flagd's own default, which the testbed's launchpad does not override. The
+launchpad's control port is exposed by the harness and must not be listed here.
 """
 
 
 @pytest.fixture(scope="session")
 def compose_backend() -> ComposeBackend:
     """The stack under test, as the TCK's ``tck_backend`` fixture wants it.
 
-    The path is absolute rather than relative to the package directory -- which
-    is what the harness resolves a relative one against, and where ``poe test``
-    runs from -- so that running pytest from the repository root works too.
+    The Compose file is the same one the flagd adoption uses -- one definition of
+    the backend, copied per package -- so it publishes flagd's two resolver ports
+    as well. Nothing here declares them, and a port nobody declares is neither
+    waited on nor looked up.
+
+    The path is absolute so that pytest run from the repository root works too;
+    a relative one resolves against the working directory.
     """
     return ComposeBackend(
         compose_file=Path(__file__).parent / "docker-compose.yaml",
@@ -65,19 +66,13 @@ def ofrep_control(tck_backend: RunningBackend, ofrep_base_url: str) -> SettledCo
     """The control API client, wrapped in a wait for the flag set to be served.
 
     ``tck_backend.control`` is the TCK's own ``HttpControl``, already pointed at
-    the launchpad's mapped port and awaited ready. The launchpad registers only
-    ``/start``, ``/restart``, ``/stop`` and ``/change`` (flagd-testbed
-    ``launchpad/main.go:29-32``), so ``/reset`` answers 404 and every
-    ``prepare_scenario`` takes the documented ``/start`` fallback. The probe
-    costs one 404 for the whole session.
-
-    Wrapped in :class:`SettledControl` because this backend's ``/start``
-    returns before it serves the flag set -- which ``control-api.yaml`` forbids
-    in those words -- and a stateless provider has no initialisation to hide
-    that window behind. See that module: it is a named workaround for one
-    backend's defect, which is where Appendix F says such a wait belongs, and it
-    is a readiness probe over the provider's own public endpoint rather than a
-    sleep.
+    the launchpad's mapped port and awaited ready. The launchpad registers no
+    ``/reset``, so every ``prepare_scenario`` takes the harness's documented
+    ``/start`` fallback and one 404 is logged per session.
+
+    Wrapped in :class:`SettledControl` because this backend's ``/start`` returns
+    before it serves the flag set, and a stateless provider has no initialisation
+    to hide that window behind. See that module.
     """
     return SettledControl(tck_backend.control, ofrep_base_url)
 
 
@@ -1,53 +1,30 @@
 """``HttpControl``, plus a wait for a backend that returns before it serves.
 
-**This is a named workaround for one backend's defect, and it belongs here
-rather than in the shared harness.** That is not a preference; it is what the
-specification prescribes. ``control-api.yaml`` requires every state-changing
-endpoint to serve the new state before it returns, and Appendix F adds that a
-suite must not paper over a backend that breaks it -- a fixed delay in the
-harness "buys silence, not correctness", is un-tunable because the window
-belongs to the backend, and would be inherited by every future adopter without
-knowing why. Where an adopter is stuck with such a backend, "the wait belongs in
-**that adoption**, set explicitly and citing the defect, so that it reads as a
-named workaround for a specific backend and disappears when the backend is
-fixed". This file is that.
-
-**The defect.** ``POST /start`` reseeds flag state to the named configuration's
-baseline and **MUST NOT return until that state is actually being served** --
-the control API says so in those words, and names this very case: "the reference
-implementation exhibits this: its ``/start`` returns roughly 40ms before flagd's
-file sources reach the flag store". flagd-testbed's launchpad returns as soon as
-flagd answers ``/readyz`` (``launchpad/pkg/flagd.go``), which flagd does before
-its file sources have been loaded into the flag store.
+**A named workaround for one backend's defect, in the adoption rather than in
+the shared harness**, which is the shape Appendix F prescribes for exactly this
+situation -- see "The control API" there for why a delay in the harness would be
+the wrong instrument.
+
+**The defect.** ``control-api.yaml`` requires ``POST /start`` not to return until
+the state it reseeded is actually being served. flagd-testbed's launchpad returns
+as soon as flagd answers ``/readyz``, which flagd does before its file sources
+have reached the flag store.
 `flagd-testbed#394 <https://github.com/open-feature/flagd-testbed/pull/394>`_
-would close it and is open and unmerged, so the window is still there. Measured
-against the pinned image it is short -- around 40ms -- but real and reliably
-hit:
-
-    start:200 {"errorCode":"FLAG_NOT_FOUND","errorDetails":"flag `float-flag` does not exist"}
-    start:200 {"value":0.5,"key":"float-flag","reason":"STATIC","variant":"half"}
-    start:200 {"errorCode":"FLAG_NOT_FOUND","errorDetails":"flag `float-flag` does not exist"}
-
-The flagd suites never see it, and that is the interesting part. Both flagd
-resolvers block inside ``initialize`` until the evaluation stream is up or the
-ruleset has synced, so their initialisation absorbs the window before any
-scenario evaluates. OFREP is stateless -- no ``initialize``, no connection, no
-warm-up -- so its first evaluation lands directly in the gap and the suite
-reports FLAG_NOT_FOUND for every flag, which reads as a catastrophically broken
-provider.
-
-**A stateless provider is the first adopter with no initialisation to hide a
-backend's warm-up behind**, which is what made it the one that found this. The
-guarantee itself is not in doubt -- "reseeded" and "serving" are already
-required to be the same instant -- so what is left is a backend that does not
-keep it, and this wait goes away the day the testbed does.
-
-**Why this is not cheating.** It manipulates nothing. It is a readiness probe
-over the same public OFREP endpoint the provider uses, on a canonical flag,
-asserting only that the backend has finished doing what ``/start`` already
-promised. No scenario is weakened, no step is bypassed, and no side channel into
-the backend is opened -- the normative control path is still ``HttpControl``,
-which this delegates to unchanged.
+explains the mechanism, measures the window and closes it; it is open and
+unmerged, so the window is still there.
+
+**Why this suite is the one that found it.** Both flagd resolvers block inside
+``initialize`` until their stream or ruleset is up, so their initialisation
+absorbs the window before any scenario evaluates. A stateless provider has no
+initialisation to hide behind: its first evaluation lands directly in the gap and
+the suite reports FLAG_NOT_FOUND for every flag, which reads as a
+catastrophically broken provider. This wait goes away the day the testbed does.
+
+**Why it is not cheating.** It manipulates nothing. It is a readiness probe over
+the same public OFREP endpoint the provider uses, on a canonical flag, asserting
+only that the backend finished what ``/start`` already promised. No scenario is
+weakened and no side channel into the backend is opened -- the normative control
+path is still ``HttpControl``, which this delegates to unchanged.
 
 Deliberately not a :class:`ConnectionControl`: it has no ``disconnect`` or
 ``reconnect``, matching a suite that declares neither ``STALE`` nor