A reviewer pass found the central claim inverted. The text said the token
never travels as a third-party cookie because fetcher.ts writes it inside the
frame. It does travel as one: activeJwtToken is a module-level variable filled
only from the response header, nothing reads the JWT cookie back, and getCookie
is called once in the whole app for XSRF-TOKEN, so the first request after a
reload sends no header and the token arrives ambiently. What spares it from
blocking is the Partitioned attribute authCookieOptions sets, which is what
#2214's control cookie exists to prove.
Consequences elsewhere in the section. Saying the upstream Partitioned work
buys no flow that does not already work was false: AUTH_SEND_JWT_HEADER ships
off, so in the default configuration nothing writes a partitioned cookie at
all. The OAuth handoff was described only in the shape that needs that upstream
work, when answering the redemption with X-JWT needs nothing upstream. The
partition-key description was a counterfactual, since a cookie with no
Partitioned attribute has no partition key, and the SameSite clause did not
apply to a top-level callback navigation under AUTH_SAME_SITE=none.
Also: the documentation gap is two edits, since the parameters page documents
the flag but still promises SameSite=Strict and a __Host- prefix that #2197
removed; #2214 adds three TLS functions and only two are table-driven; the task
list still claimed R1 has no e2e coverage; the constraint bullet still described
setAuthCookie's pre-#2197 behaviour; and the Path B cost line had swapped the
real upstream dependency for an invented one. Wrapped to 100 columns.
Dmitry Verkhoturov
be61b5873a