fix: pre-landing review fixes

Co-authored-by: capy-ai[bot] <230910855+capy-ai[bot]@users.noreply.github.com>

BROWSER.md

@@ -311,7 +311,7 @@ $B connect                       # headed Chromium + Side Panel extension
 9. [Side Panel + sidebar agent](#side-panel--sidebar-agent)
 10. [Pair-agent — remote agents over an ngrok tunnel](#pair-agent)
 11. [Authentication + tokens](#authentication)
-12. [Prompt-injection security stack (L1–L6)](#security-stack)
+12. [Prompt-injection security stack (L1–L6)](#security-stack) — including [TLS trust: the bundled Chromium's root store](#tls-trust-the-bundled-chromiums-root-store)
 13. [Screenshots, PDFs, visual inspection](#screenshots-pdfs-visual)
 14. [Local HTML — `goto file://` vs `load-html`](#local-html)
 15. [Batch endpoint](#batch-endpoint)
@@ -1303,25 +1303,29 @@ into its bundled Playwright Chromium. The default headless browser never gets
 the CRLSet revocation updates Chrome pushes to running browsers. Headed mode and
 `handoff` do fetch them, but only about a minute after each launch, so the
 first pages they open, including the page `handoff` reopens, are checked
-against the compiled root store alone. The bundled build does not enforce
-Certificate Transparency. That matters most for the flows that put real
-sessions and credentials into the browser: `cookie-import-browser`,
-`fill`/`type`, and `handoff`. Aside uses your own browser's trust store and
-updates.
+against the compiled root store alone. `BROWSE_EXTENSIONS_DIR` makes the
+headless browser launch like headed mode, and `GSTACK_CHROMIUM_PATH` replaces
+the bundled build, so its trust is whatever that binary trusts. The bundled
+build does not enforce Certificate Transparency. That matters most for the
+commands that put real sessions and credentials into the browser:
+`cookie-import-browser`, `cookie-import`, `cookie`, `header`,
+`fill`/`type` and `handoff`, and a paired agent driving any of them. Aside
+uses your own browser's trust store and updates.
 
 **Known gap: the compromised eMudhra intermediates
 ([#3338](https://github.com/garrytan/gstack/issues/3338)).** Chrome blocked them
-by CRLSet on 2026-10-17 and removes their root, emSign ECC Root CA - G3, from
-the Chrome Root Store on 2026-10-27. gstack's pinned Playwright 1.62.1
-(Chromium 151), the latest release 1.64.1 (Chromium 156) and the 1.65
-alphas (Chromium 157) still trust them, so
+by CRLSet on 2026-10-17, the day the compromise was reported, and scheduled the
+removal of their root, emSign ECC Root CA - G3, from the Chrome Root Store for
+2026-10-27. gstack's pinned Playwright 1.62.1 (Chromium 151), the latest release
+1.64.1 (Chromium 156) and the 1.65 alphas (Chromium 157) still trust them, so
 `$B goto https://dv-g3b-emudhra.we-have-a-problem.com/` loads a page saying
 "That's bad!" instead of failing with `ERR_CERT_AUTHORITY_INVALID` (headed mode
 fails it with `ERR_CERT_REVOKED` once its CRLSet arrives). gstack will move to
 the first Playwright release whose Chromium carries the removal. Until then,
 don't import cookies or type credentials in this engine on a network you do not
-trust, and prefer Aside for signed-in work where you have it. The same `goto`
-tells you when your build is fixed.
+trust, and prefer Aside for signed-in work where you have it. To check a build,
+run the same `goto`: only `ERR_CERT_AUTHORITY_INVALID` or `ERR_CERT_REVOKED`
+means it no longer trusts them. A DNS, network or other error proves nothing.
 
 ---
 

CHANGELOG.md

@@ -2,10 +2,10 @@
 
 ## [Unreleased]
 
-**BROWSER.md now says that gstack's own browser still trusts the compromised eMudhra intermediates, and how to check (#3338).** Chrome blocks the eight eMudhra intermediate CAs whose keys leaked on 2026-10-17 with a CRLSet push, and removes their root, emSign ECC Root CA - G3, from the Chrome Root Store on 2026-10-27. gstack's fallback browser gets neither in time: its default headless browser never receives CRLSet updates, headed mode and `handoff` receive them only about a minute after each launch, and the root store compiled into the bundled Chromium still trusts the root. On 2026-10-24, `$B goto https://dv-g3b-emudhra.we-have-a-problem.com/` returned 200 and "That's bad!" on gstack's pinned Playwright 1.62.1 (Chromium 151.0.7922.34). The same check against Playwright 1.64.1 (Chromium 156.0.8078.4) and the 1.65.0 alpha of 2026-10-24 (Chromium 157.0.8103.15) also loaded the page. Chrome for Testing builds from 158.0.8115.0 fail it with `ERR_CERT_AUTHORITY_INVALID`, so a Playwright bump has to wait for a release that bundles one of those builds.
+**BROWSER.md now says that gstack's own browser still trusts the compromised eMudhra intermediates, and how to check (#3338).** Chrome blocked the eight eMudhra intermediate CAs with a CRLSet push on 2026-10-17, the day their key compromise was reported, and scheduled the removal of their root, emSign ECC Root CA - G3, from the Chrome Root Store for 2026-10-27. gstack's fallback browser gets neither in time: its default headless browser never receives CRLSet updates, headed mode and `handoff` receive them only about a minute after each launch, and the root store compiled into the bundled Chromium still trusts the root. On 2026-10-24, `$B goto https://dv-g3b-emudhra.we-have-a-problem.com/` returned 200 and "That's bad!" on gstack's pinned Playwright 1.62.1 (Chromium 151.0.7922.34). The same check against Playwright 1.64.1 (Chromium 156.0.8078.4) and the 1.65.0 alpha of 2026-10-24 (Chromium 157.0.8103.15) also loaded the page. Chrome for Testing builds from 158.0.8115.0 fail it with `ERR_CERT_AUTHORITY_INVALID`, so a Playwright bump has to wait for a release that bundles one of those builds.
 
 ### Changed
-- **`BROWSER.md`**: a new "TLS trust: the bundled Chromium's root store" section, at the end of the security stack, says the fallback engine checks certificates against that compiled root store, that the headless browser never gets CRLSet updates while headed mode and `handoff` get them about a minute after launch, and that the bundled build does not enforce Certificate Transparency. It names the flows that put real sessions and credentials into the browser (`cookie-import-browser`, `fill`/`type`, `handoff`) and gives the one-line `$B goto` check. The fallback-engine introduction and the `cookie-import-browser` and `handoff` command rows link to it. Aside is unaffected, because it is your own browser with its own updates.
+- **`BROWSER.md`**: a new "TLS trust: the bundled Chromium's root store" section, at the end of the security stack, says the fallback engine checks certificates against that compiled root store, that the headless browser never gets CRLSet updates while headed mode and `handoff` get them about a minute after launch, and that the bundled build does not enforce Certificate Transparency. It names the commands that put real sessions and credentials into the browser (`cookie-import-browser`, `cookie-import`, `cookie`, `header`, `fill`/`type`, `handoff`, and a paired agent driving them), says how `BROWSE_EXTENSIONS_DIR` and `GSTACK_CHROMIUM_PATH` change the picture, and gives the one-line `$B goto` check, where only a certificate error means a build is fixed. The table of contents, the fallback-engine introduction and the `cookie-import-browser` and `handoff` command rows link to it. Aside is unaffected, because it is your own browser with its own updates.
 
 ### For contributors
 - The edits above the cookie workflow excerpt change no line count, so the `setup-browser-cookies/SKILL.md workflow` judge input is byte-identical (prompt SHA-256 `c851e635…`, 12,805 bytes, before and after).