@@ -1,64 +1,31 @@
 """One testbed stack, declared rather than wired, and shared by both suites.
 
-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 and one free port for the scenarios that need a backend that
-is not there.
-
-One stack and one ``HttpControl`` serve both suites, because one flagd process
-serves both resolver ports: 8013 for RPC and 8015 for sync. The launchpad
-registers no ``/reset`` and no ``/healthz``, so every ``prepare_scenario`` takes
-the harness's documented ``/start`` fallback and one 404 is logged per session.
-
-**What a full run reports, and what each failure is.** ``8 failed, 119 passed,
-3 skipped`` over the two resolvers. Read it here rather than counting: three
-distinct causes account for all eight, and only two of them are the provider's.
-
-*Six failures are the backend's flag set.* no released flagd-testbed seeds
-``large-integer-flag`` nor ``integral-float-flag``, so the untagged precision
-scenario, the ``max-int32`` row of the ``@variants`` outline and the lossless
-``@numeric-coercion`` scenario fail ``FLAG_NOT_FOUND`` on each resolver alike.
-open-feature/flagd-testbed#392 seeds all three of the flags the canonical set is
-missing and says what each catches; bump the tag in ``docker-compose.yaml``
-beside this file when it lands. Left as failures rather than xfailed, because
-they are true about the stack under test, and carrying no ``KnownDeviation`` in
-either suite: the provider was never given the flag to get wrong.
-
-*One failure is ``openfeature-flagd-core``'s*, on in-process alone:
-``boolean-flag`` requested as a Float resolves to ``1.0`` with reason ``STATIC``
-and no error code, where the mandatory wrong-type scenario asks for the caller's
-default. ``bool`` is a subclass of ``int`` in Python and the int-to-float
-widening does not exclude it. Filed as open-feature/python-sdk-contrib#417. RPC
-passes the row, because the server type-checks it. No ``KnownDeviation``: the
-scenario is mandatory and ungated, so it fails visibly on every run and an entry
-would add nothing a reader cannot see.
-
-*One failure is flagd's*, on RPC alone, and it is the one failure here carrying a
-``KnownDeviation``: ``float-flag`` (0.5) requested as an Integer comes back as
-``0`` with no error code. **The in-process resolver passes that scenario**, which
-is why the deviation is recorded against RPC only; ``test_rpc.py`` and
-``test_in_process.py`` carry the measurement on each side.
-
-*The three skips are two scenarios.* ``@large-integers`` gates one and is
-withheld on both resolvers, so it skips twice; ``@reinitialization`` gates one,
-which in-process declares and passes and RPC withholds, so it skips once. Each
-suite gives its own reason beside its declaration.
-
-**One finding came out of a scenario that passes**, so neither the results nor
-the report has anywhere to put it: the in-process *Shutting down a provider that
-cannot reach its backend completes promptly* returns well inside its bound and
-leaves a ``PytestUnhandledThreadExceptionWarning`` behind it -- gRPC's
-connectivity polling thread raising ``ValueError: Cannot invoke RPC: Channel
-closed!`` after ``shutdown`` closed the channel underneath it. Reproducible on
-every run, and filed as open-feature/python-sdk-contrib#419. Not a deviation:
-nothing required is unmet. It is noted here because a reader who sees the warning
-should know it is a recorded finding rather than noise.
-
-The canonical set's ``targeting-key-flag``, four ``disabled-*`` flags and three
-falsy flags need no testbed change: they are flagd-testbed's own flags, which is
-why the canonical set adopted their names and variants, and the launchpad's
-``default`` configuration serves them as they stand.
+One flagd process serves both resolver ports -- 8013 for RPC, 8015 for sync --
+so one stack and one ``HttpControl`` serve both suites.
+
+**A full run is ``8 failed, 119 passed, 3 skipped``.** All eight failures have
+one of three causes, and only two of them are the provider's:
+
+* Six are the backend's flag set. No released flagd-testbed seeds
+  ``large-integer-flag`` or ``integral-float-flag``, so three scenarios fail
+  ``FLAG_NOT_FOUND`` on each resolver alike. open-feature/flagd-testbed#392
+  seeds them; bump the tag in ``docker-compose.yaml`` beside this file when it
+  lands. Carrying no ``KnownDeviation``: the provider was never given the flag.
+* One is ``openfeature-flagd-core``'s, on in-process alone. ``boolean-flag``
+  requested as a Float resolves to ``1.0`` rather than the caller's default,
+  because ``bool`` is a subclass of ``int``: python-sdk-contrib#417. RPC passes
+  the row, because the server type-checks it.
+* One is flagd's, on RPC alone, and is the only failure here carrying a
+  ``KnownDeviation``: ``float-flag`` (0.5) as an Integer comes back as ``0``.
+  In-process passes that scenario, hence the deviation on RPC only.
+
+The three skips are two scenarios: ``@large-integers``, withheld on both
+resolvers, and ``@reinitialization``, withheld on RPC alone.
+
+One finding has nowhere else to go, because its scenario *passes*: in-process
+shutdown-under-outage leaves a ``PytestUnhandledThreadExceptionWarning`` from
+gRPC's connectivity thread behind it on every run, python-sdk-contrib#419. Noted
+so a reader knows the warning is recorded rather than noise.
 """
 
 from __future__ import annotations
@@ -74,13 +41,10 @@
 
 @pytest.fixture(scope="session")
 def compose_backend() -> ComposeBackend:
-    """The stack under test, as the TCK's ``tck_backend`` fixture wants it.
+    """The stack under test, for the TCK's ``tck_backend`` fixture.
 
     Both resolver ports are declared even though each suite uses one of them,
-    because both suites share this stack. The Compose file publishes flagd's
-    OFREP port as well, which nothing here asks for: it is the same file the
-    OFREP adoption uses, and a port nobody declares is neither waited on nor
-    looked up.
+    because both suites share this stack.
 
     The path is absolute so that pytest run from the repository root works too;
     a relative one resolves against the working directory.
@@ -98,8 +62,7 @@ def closed_port(tck_backend: RunningBackend) -> int:
     Discovered by binding and releasing rather than hard-coded, because the
     stack's own host ports are mapped dynamically and a fixed number could
     collide with one; depending on ``tck_backend`` orders this after the stack
-    has taken its ports. Deliberately not a port on the stack, which has to stay
-    up -- simulated outages belong to the control API.
+    has taken its ports.
     """
     with socket.socket(socket.AF_INET, socket.SOCK_STREAM) as probe:
         probe.bind(("127.0.0.1", 0))
 
@@ -1,17 +1,11 @@
 """Shared wiring for the two flagd conformance suites.
 
 flagd resolves flags two quite different ways -- RPC evaluates remotely over
-gRPC, in-process syncs the ruleset and evaluates locally -- and they are separate
-suites because they are separately conformant. Any difference between the two
-results is a difference an application would see when it switches resolver,
-which is exactly the class of thing the conformance suite exists to surface.
-
-Everything they share lives here; everything that differs lives in ``test_rpc.py``
-and ``test_in_process.py`` next to it, where a reader can see the whole of a
-resolver's declaration in one place. The TCK owns the container stack (see
-``conftest.py``), so what is left here is the timings, which are flagd's own and
-interact, and the one function that turns a resolver plus a running endpoint into
-a ``TckConfig``.
+gRPC, in-process syncs the ruleset and evaluates locally -- and they are
+separate suites because they are separately conformant. What is shared is the
+timings, which are flagd's own and interact, and the one function that turns a
+resolver plus a running endpoint into a ``TckConfig``; what differs lives in
+``test_rpc.py`` and ``test_in_process.py``.
 """
 
 from __future__ import annotations
@@ -34,23 +28,18 @@
 IN_PROCESS_PORT = 8015
 """Container-internal ports flagd serves remote evaluation and the sync stream on.
 
-Both are declared in one ``ComposeBackend`` because one flagd process serves both
-and both suites share the stack. Named here rather than in ``conftest.py`` so
-that the declaration and the resolver that uses it cannot drift apart.
+Named here rather than in ``conftest.py`` so that the declaration and the
+resolver that uses it cannot drift apart.
 """
 
-# Timings. flagd exposes several and they interact, so they are named here once
-# rather than scattered through two suites.
-
 DEADLINE_MS = 5000
 """How long a provider blocks during initialisation before giving up.
 
 This, and not ``TckConfig.ready_timeout``, is what actually bounds flagd's
 initialisation: the resolvers block inside ``initialize`` and raise
 ``ProviderNotReadyError`` when it expires (grpc.py:175, grpc_watcher.py:151).
-Generous because every scenario is preceded by a control-API ``/start``, which
-restarts the flagd process -- so a provider is routinely built against a backend
-that came up milliseconds ago.
+Generous because every scenario is preceded by a control-API ``/start``, so a
+provider is routinely built against a backend that came up milliseconds ago.
 
 For the RPC resolver it also bounds each individual resolution call.
 """
@@ -61,28 +50,25 @@
 RETRY_BACKOFF_MAX_MS = 5000
 """Longest delay between reconnect attempts, and the wait between stream retries.
 
-Kept at or above :data:`DEADLINE_MS`: the provider passes the deadline to gRPC as
-``grpc.min_reconnect_backoff_ms`` and this as ``grpc.max_reconnect_backoff_ms``
-(grpc.py:90-92), so a smaller value here would be a channel configured with a
-minimum backoff above its maximum.
+Kept at or above :data:`DEADLINE_MS`: the provider passes the deadline to gRPC
+as ``grpc.min_reconnect_backoff_ms`` and this as
+``grpc.max_reconnect_backoff_ms`` (grpc.py:90-92), so a smaller value here would
+be a channel configured with a minimum backoff above its maximum.
 """
 
 RETRY_GRACE_PERIOD_SECONDS = 30
 """How long a disconnected provider stays STALE before escalating to ERROR.
 
-Load-bearing for the ``@stale`` scenario. Both resolvers go STALE the moment the
-channel fails and start a timer that escalates to ERROR when this expires
-(grpc.py:204-210, grpc_watcher.py:180-186). Too short a value turns a scenario
-about staleness into one about failure, because the outage lasts as long as the
-scenario needs to observe it.
+Load-bearing for the ``@stale`` scenario: both resolvers start the escalation
+timer the moment the channel fails (grpc.py:204-210, grpc_watcher.py:180-186),
+so too short a value turns a scenario about staleness into one about failure.
 """
 
 STREAM_DEADLINE_MS = 0
 """Disable periodic stream recycling, as the existing e2e suites do.
 
-A recycle is invisible to the provider contract, but disabling it removes a
-source of background reconnects from a suite whose whole subject is what a
-reconnect looks like.
+It removes a source of background reconnects from a suite whose whole subject
+is what a reconnect looks like.
 """
 
 UNAVAILABLE_DEADLINE_MS = 500
@@ -92,9 +78,9 @@
 
 The ``@unavailable`` scenarios assert that failure is reported *promptly*, so a
 provider taking 30 seconds to give up would pass a test about eventual failure
-while failing the one that matters. The backoff is long for the opposite reason:
-after the error is reported, the next failed reconnect attempt would emit
-another ``PROVIDER_STALE`` and move the provider out of the ERROR state the
+while failing the one that matters. The backoff is long for the opposite
+reason: after the error is reported, the next failed reconnect attempt would
+emit another ``PROVIDER_STALE`` and move the provider out of the ERROR state the
 scenario is about to assert.
 """
 
@@ -117,16 +103,12 @@ class ResolverSuite:
     resolver_type: ResolverType
 
     backend_port: int
-    """The container-internal port this resolver connects to.
-
-    Resolved to a host port through the endpoint, after the stack is up.
-    """
+    """Container-internal port, resolved to a host port once the stack is up."""
 
     capabilities: frozenset[Capability]
     """What this resolver was run against the suite and seen to satisfy.
 
-    See each suite module for the evidence behind every entry, and behind every
-    omission.
+    See each suite module for the evidence behind every entry and omission.
     """
 
     ready_timeout: float
@@ -135,11 +117,10 @@ class ResolverSuite:
     """Requirements this resolver is known to fail, acknowledged rather than hidden.
 
     **Per resolver, and that is the whole reason this field is here rather than
-    shared.** The two resolvers do not deviate alike: RPC narrows ``float-flag``
-    to ``0`` where in-process refuses it, so an entry naming
-    :attr:`~Capability.NUMERIC_COERCION` is true of one and false of the other,
-    and attaching it to both would publish a defect against the resolver that
-    does not have it.
+    shared.** RPC narrows ``float-flag`` to ``0`` where in-process refuses it,
+    so an entry naming :attr:`~Capability.NUMERIC_COERCION` is true of one and
+    false of the other, and attaching it to both would publish a defect against
+    the resolver that does not have it.
     """
 
 
@@ -150,9 +131,8 @@ def build_config(
 ) -> TckConfig:
     """Wire one resolver up to the running testbed.
 
-    The host and port are read off ``backend.endpoint`` inside the factory, which
-    is why the factory exists: the mapped host port does not exist until the
-    stack is up. The host comes from the endpoint rather than being written as
+    A factory because the mapped host port does not exist until the stack is up.
+    The host comes from the endpoint rather than being written as
     ``"localhost"``, because with a remote Docker daemon, Docker Desktop on some
     platforms or a rootless setup it is neither localhost nor predictable.
     """
@@ -171,9 +151,8 @@ def new_provider() -> FeatureProvider:
         )
 
     def new_unavailable_provider() -> FeatureProvider:
-        # Pointed at a closed port on localhost, never at the backend under
-        # test: that has to stay up, and simulated outages belong to the control
-        # API.
+        # A closed port on localhost, never the backend under test: that has to
+        # stay up for every other scenario.
         return FlagdProvider(
             resolver_type=suite.resolver_type,
             host="localhost",