Document protected live authenticated sessions

README.md

@@ -8,6 +8,8 @@ The substrate supports multiple frontends over the same browser-owned state. A c
 
 The browser core owns resource, tab, event, and task identity; sleeping and waking; snapshots; organization; indexes; inference acceptance; and renderer selection. Only roughly 3–10 renderer working sets should normally be resident even when the known corpus reaches 10,000 resources.
 
+Low-memory behavior has a harder exception: an active authenticated transaction may be protected from ordinary sleeping or eviction. Opening another tab or app to retrieve information must not silently destroy the login/session or in-progress form state. See `docs/architecture.md` and #59.
+
 ## Design notes
 
 - `docs/architecture.md` — ownership and replaceable-service boundaries

docs/architecture.md

@@ -15,6 +15,7 @@ The browser core owns:
 - resource, tab, event, and task identity;
 - navigation and search history;
 - sleeping and waking policy;
+- authenticated site-session and protected-transaction policy;
 - task and investigation frontiers;
 - saved representations and snapshot references;
 - user organization, assertions, corrections, and active choices;
@@ -84,6 +85,18 @@ A sleeping tab has no renderer session and consumes approximately the cost of pe
 
 A 10,000-resource or history corpus does not imply 10,000 logical tabs or live documents. The current developer fixture deliberately separates 10,000 known URLs, 32 logical tabs, and a 3–10-tab resident working set. Steady-state renderer RAM should follow the resident set, not corpus size.
 
+## Protected live sessions
+
+Sleeping is not appropriate for every active tab. Some tabs are live authenticated transactions: a government or benefits form, banking or healthcare workflow, or another fragile interaction where the user may need to open another tab or app to retrieve information before continuing.
+
+A protected live session is browser-owned policy over the tab, renderer, and authentication/session state. Ordinary renderer eviction must prefer unprotected work before discarding a protected transaction. Cookies, site-session material, navigation position, and other state required to continue the transaction must not be treated as disposable merely because the current renderer process owns an implementation handle to them.
+
+On a low-memory device, opening another tab or app must not silently destroy a protected transaction and force the user to begin again. If renderer or process death is unavoidable, IB should reconstruct the strongest safe continuation it can from browser-owned state and report any restoration limit explicitly.
+
+This requirement does not promise exact JavaScript-heap continuity across renderer changes or process death. It also does not justify blindly persisting passwords, account numbers, or other sensitive field contents. The security and persistence boundary for protected transactions must be explicit.
+
+Acceptance must distinguish at least session-cookie survival, form-state survival, live-renderer survival, and reconstruction after renderer death. Evidence for one is not evidence for the others. See #59.
+
 ## Renderer swapping
 
 The core selects a renderer through a narrow adapter contract. Swapping renderers must not change resource, tab, event, task, organization, or stored-representation identity.