Keep transports in one browser window

docs/architecture.md

@@ -14,13 +14,11 @@ isolation decisions outside the browser engine until those contracts are stable.
 4. Adopt healthy existing transports.
 5. If the selected transport is missing, show a first-use prompt before setup.
 6. Start or install managed transports only after user consent.
-7. Open the URL with the matching isolated profile.
+7. Continue in a tab carrying the matching transport context.
 
-The clearnet entry profile is a broker, not a mixed-network profile. It uses direct
-clearnet networking. Its extension blocks all `.onion` and `.i2p` requests from that
-profile. For a top-level navigation, it asks a token-gated loopback helper to apply the
-normal route and consent policy, then opens the destination in a separate transport
-profile and browser process.
+AMPB has one visible browser window. Each web tab belongs to a named transport container.
+A top-level route change replaces that tab in the same window; subresources cannot change
+transport. The container controls site-data separation and fail-closed proxy policy.
 
 ## Main Components
 
@@ -28,8 +26,6 @@ profile and browser process.
 - `ampbrowser.adapters`: transport ownership, setup, inspection, and health contracts.
 - `ampbrowser.transports`: local readiness checks for Tor, I2P, IPFS, Reticulum, and Gemini.
 - `ampbrowser.plan`: dry-run action planner for browser launches.
-- `ampbrowser.broker`: validated handoff from the clearnet entry profile to an isolated
-  transport profile.
 - `ampbrowser.launch`: side-effect-free launch specs and first-use consent state.
 - `ampbrowser.platforms`: platform capability matrix for desktop, Android, and iOS.
 - `ampbrowser.candidates`: evaluated transport candidates before active adapter support.
@@ -48,9 +44,9 @@ Browser equivalence until it tracks the relevant Tor Browser hardening, fingerpr
 proxy, and update behavior. AMPB should not depend on system Firefox, system Chrome, or
 the user's default browser.
 
-The long-term browser can become a deeper Firefox, GeckoView, or Tor Browser fork once
-the orchestration surface is reliable: profile isolation is predictable, transport adoption
-is boring, and generated fixtures from AMPG open without manual proxy setup.
+The release browser requires a reviewed Firefox/Gecko integration. Transport context must
+be carried below WebExtensions through origin attributes, channel load information,
+connection pools, storage, cache, service workers, and content-process selection.
 
 Generated backend metadata lives in
 [generated browser strategy](generated/browser-strategy.md).
@@ -59,16 +55,17 @@ The first implementation path is documented in [desktop vertical](desktop-vertic
 
 ## Isolation Boundaries
 
-- Browser storage is isolated by transport profile.
+- The prototype isolates cookies and site data with Firefox transport containers.
 - Transport runtime state is isolated under AMPB-owned transport directories when AMPB
   manages the daemon.
-- A transport profile remains sticky: ordinary navigation stays in that profile and uses
+- A transport context remains sticky: ordinary navigation stays in that context and uses
   its configured proxy until the user explicitly starts a different context.
 - The loopback helper accepts a random per-launch token and recomputes the URL route before
-  opening it. A caller cannot label an I2P URL as Tor or vice versa.
+  managing it. Web content cannot invoke transport management directly.
 
-These controls prevent accidental browser-state mixing. They do not by themselves provide
-Tor Browser fingerprinting resistance or make non-anonymous transports anonymous.
+Container controls do not separate all Firefox profile state and do not by themselves
+provide Tor Browser fingerprinting resistance. Release anonymity claims require the native
+Gecko boundary and tracked Tor Browser hardening.
 
 ## Relationship To AMPG