[Browser Session] Mint presentation mutation authority from owned lifecycle

Buyer / DDD gap

PR #229 now makes viewport/DPR/timezone and screen-area mutation fail closed behind opaque ownership witnesses, but OriginWeave still has no production Browser Session lifecycle that can legitimately mint those witnesses. The current fail-closed state is safer than accepting a raw browsing-context id, but it leaves the presentation application path intentionally unusable until browser ownership is modeled as domain authority rather than adapter addressability.

This issue owns that missing Browser Session bounded context. It does not move WebDriver BiDi policy authority into the driver/MCP adapter and does not authorize a public constructor for WebDriverBidiPresentationOwnership or WebDriverBidiScreenAreaOwnership.

Ubiquitous language and aggregate boundary

Model an explicit Browser Session aggregate whose authority is established before adapter commands exist.

Suggested domain concepts, adjusted to the live codebase rather than copied mechanically:

aggregate: BrowserSession
entity: BrowsingContext
value objects: BrowserSessionId, BrowsingContextId, BrowserContextOwnership, PresentationMutationAuthority, PresentationPredecessorState
domain events: BrowserSessionStarted, BrowsingContextCreated, PresentationAuthorityGranted, PresentationStateCaptured, PresentationStateRestored, BrowsingContextDestroyed, BrowserSessionEnded
repository: durable session/evidence repository only where persistence is actually required; browser transport state is not database truth
adapter ACL: map a domain-owned authority witness to version-pinned WebDriver BiDi/CDP command intent without letting the adapter mint authority

The names above are a design starting point. Final code/API/test names must match the actual bounded-context language and multiword snake_case database conventions where a database is justified.

Core invariants

A remote/browser-issued browsing-context identifier proves addressability only. It must never mint presentation mutation authority by itself.
PresentationMutationAuthority may be issued only when Browser Session proves either:
- an exclusive/disposable context/profile whose complete destruction is owned by that session; or
- exact predecessor-state capture plus a restoration contract that can prove the original state after cleanup.
Apply and cleanup authority are symmetric and tied to the same session/context epoch. Navigation/renderer replacement, context transfer, session expiry, crash, or ownership loss invalidates stale authority unless the lifecycle explicitly re-establishes it.
Generic cleanup must never clear another owner's viewport, DPR, timezone, screen-area or related emulation override.
A BiDi/CDP/WebDriver command ACK is not successful mutation or restoration evidence. Browser-observed post-condition or proven destruction is required.
Unsupported/partial predecessor capture, ambiguous ownership, cleanup failure, renderer/process failure, or stale epoch fails closed.
Browser Session owns lifecycle/authority. originweave-bidi and MCP/driver code remain adapters; policy and browser-domain truth stay outside those adapters.
No LLM/model verdict may replace deterministic ownership, cleanup, or browser post-condition checks.

Test-first acceptance

Start from a hostile/reuse RED that demonstrates the current reason witnesses have no public mint path:

two logical owners address the same reusable browsing context;
owner A has a pre-existing viewport/DPR/timezone or screen-area override;
owner B cannot obtain mutation authority merely from the shared context id;
an attempted generic reset cannot erase A's predecessor state.

Then add the minimum Browser Session lifecycle needed to make one safe path GREEN. Prefer the disposable-owned-context path first if it is materially simpler and produces stronger teardown evidence; do not invent predecessor snapshot support that the active protocol/browser revision cannot actually observe or restore completely.

Exact-head tests must cover at least: exclusive creation, authority mint, stale/foreign context rejection, duplicate/idempotent transition behavior, session/context epoch invalidation, crash/forced-close, destroy/cleanup failure, and no cross-session authority reuse. Owned production function/line/region/branch coverage and public rustdoc remain 100%.

Real Chromium acceptance

Synthetic fixtures are unit tests only. Before this issue can be considered implemented, pinned Chromium must prove the chosen lifecycle on the exact head:

owned context/profile creation → authority mint → presentation apply → page-observed post-condition → native interaction/post-condition where applicable → cleanup/destruction → proof that no task-owned context/profile/process remains.

For a reusable-state implementation, additionally prove exact predecessor capture and browser-observed restoration. For a disposable implementation, prove destruction rather than interpreting reset ACK as restoration.

The current #299 evidence is not this GREEN: it remains pre-navigation 0/3 WebDriverSessionNotCreatedError and never reaches presentation surfaces.

Integration order

Treat feat: add privacy-preserving presentation identity kernel #229's opaque ownership-witness lineage as the adapter-side prerequisite; do not edit that active source lane while its single-writer lease is held.
Implement Browser Session as its own reviewed bounded-context slice after the feat: add privacy-preserving presentation identity kernel #229 ownership contract is stable/released into the parent lineage.
Consume the released/normal-integrated adapter contract through an ACL; do not copy mutable source across branches/services.
Re-run feat(browser): bind presentation identity to versioned Chromium emulation evidence #292/test(browser): observe pinned presentation cleanup #299 buyer acceptance only after the canonical Chromium workflow/sandbox path ([Governance] Repair MV3 workflow ownership and sandbox contract #212 / central .github) is protected and usable.
Keep contextual-orchestrator, Keyverse, Wardnet and EgressWeave in their own canonical ownership domains.

Documentation / decision record

When executable behavior exists, update ARCHITECTURE, PRD/TRD, UML, ADR/doctoring/traceability, TEST_STRATEGY, OPERABILITY/recovery and docs/product-technical-gap-baseline.md with the problem, alternatives (disposable lifecycle vs predecessor capture/restore), selected/rejected rationale, exact evidence, failure/recovery semantics and reversal path. Do not mark the ADR Accepted before the exact-head lifecycle and real-browser evidence exist.

Non-goals

public raw-context ownership constructors;
JavaScript/CDP escape hatches to manufacture state truth;
cross-service SQL or mutable sibling-branch dependency;
browser sandbox weakening or --no-sandbox;
treating cleanup bookkeeping, command ACK or another head's browser result as acceptance;
duplicating central workflow/model/egress/secret authority.

Depends on #229 and feeds #292/#299. Workflow/sandbox mechanics remain #212; ChromeDriver startup diagnosis remains #148.

Writer lease ACTIVE — exact prerequisite is #229 head 7ec83c1be1a8e8724d37c2d6ebbdb215b1b10e23; its branch remains owned by a separate active writer and will not be mutated. Scope is a new stacked successor only: hostile repository-contract RED for missing Browser Session lifecycle authority → minimum domain-only Rust aggregate for disposable owned contexts → exact-head repository verification. The slice will not add a public raw-context ownership constructor, WebDriver/CDP policy authority, workflow/ruleset/secret changes, force update/rebase, self-approval, merge, tag, release, sandbox weakening, provider/model pinning, or #148/#299 mutation.

#313 repair advanced from the exact 797157a RED to current 91c0b82845978de202c59abc875233cd367a9788 without touching #229. Hosted RCA for 797157a is now exact: Rust-contract job 102744511014 ran 175 Python tests and failed only because docs/README.md omitted ADR 0114; coverage job 102744510755 reached 100% functions/lines/branches but 485/487 regions (99.5893%), leaving inactive-session branches in presentation_authority/advance_context_epoch uncovered. Both are repaired in the successor head.

The valid cross-aggregate alias finding is also repaired at the domain/port boundary rather than with an aggregate-only nonce. DisposableContextPort now returns a DisposableContextHandle containing a non-aliasing DisposableIsolationId plus BrowsingContextId; PresentationMutationAuthority binds session+isolation+context+epoch; destruction validates before I/O and passes the stored isolation handle back to the port. The hostile test gives two aggregates the same BrowserSessionId, same BrowsingContextId, and same local epoch but distinct isolation ids: B rejects A authority with zero destroy I/O, and B's own authority can address only B's isolation handle. For WebDriver BiDi the port proof obligation is a one-to-one mapping to the spec-defined unique user-context id; an unchecked random adapter token is explicitly insufficient.

Current exact CI 34440252089 is queued pre-execution (runner_id=0, steps=[] for Rust contracts 102753617548 and coverage 102753617293), so no GREEN claim or merge yet. ADR 0114, both ADR indexes, traceability and lifecycle UML are synchronized; real BiDi user-context adapter/post-condition and #299 3/3 Chromium replay remain later acceptance.

New exact-current lifecycle finding on #313 6486e916dceb4ab5f33f7b390cd76fd4673d6007: partial creation cleanup is not representable yet. DisposableContextPortError::CreateFailed collapses clean pre-boundary failure and cleanup-uncertain partial creation, while BrowserSession::create_disposable_context records no handle and leaves the aggregate Active. A real BiDi adapter can create a user context successfully before browsingContext.create fails; if browser.removeUserContext then fails or is unproven, the current aggregate could later end clean with an external isolation boundary untracked. Review 5163111537 keeps this blocking. Required hostile RED: cleanup-uncertain partial creation must make clean end impossible. Minimum repair should distinguish clean failure from recovery-required partial creation (or carry a recovery handle) and require proven destruction before normal end. This is separate from the repaired cross-aggregate isolation-alias path.

Current causal repair is stacked child #315 at exact 889d1964b8b4a63e4bec4a4dff08061efadc43b0 on #313 predecessor 6486e916dceb4ab5f33f7b390cd76fd4673d6007. The child now distinguishes proved-clean creation failure from uncertain/partial creation, enters RecoveryRequired for uncertain or duplicate adapter outcomes, invalidates active authority, and retains one validated mutable ownership record across destroy I/O. This addresses the false-normal-end finding without conflating ownership uncertainty with proven transport loss. Exact-head CI 34444080811 is currently pre-execution queued (runner_id=0, no steps) and therefore is neither RED nor GREEN. Parent #313 remains untouched and its review thread remains unresolved until child evidence is complete and normally adopted.

#315 causal repair advanced after hosted evidence. Exact 889d1964b8b4a63e4bec4a4dff08061efadc43b0 CI 34444080811 actually executed: Production coverage 102764975364 passed exact function/line/region/branch enforcement; Rust contracts 102764975519 passed repository contracts and failed only canonical formatting. The rustfmt diagnostic artifact 10139210810 (sha256:95c6508ca1d339a52c28c891a888cdfad412a9d16ccd8cd80a152e39f2ae8547) contained only two line-wrap changes in the clean/uncertain creation test. Those exact canonical formatting changes were applied as normal successor commit 09a733a8609b54abfb7a4f6509b9eb9c064b9b2d; resulting source blob 7765fbf9fa041fc6d40dfcecee1bcc3624a6fd44 matches the artifact target blob. New exact-head CI 34445816137 is currently queued with no runner/steps, so it is neither RED nor GREEN and earlier coverage evidence is not transferred. #313 remains untouched and its duplicate-output review thread remains unresolved until child exact-head evidence and ordinary adoption.

Exact-current #315 98a28db0ac95972419906f229badf35c4f5fa0d6 review 5164398667 adds a recovery-evidence prerequisite. The slice now correctly enters RecoveryRequired for uncertain create/duplicate output, but CreateFailedUncertain carries no partial isolation identity and duplicate-output branches discard the returned DisposableContextHandle. A real BiDi adapter can have a valid browser.createUserContext id before later browsing-context creation/verification becomes uncertain; losing that id makes later reconciliation unable to target or attest the potentially leaked boundary. Required hostile RED: preserve the exact user-context/isolation recovery identity after partial create while blocking normal authority/end; also preserve the offending identity for duplicate-context/distinct-isolation and duplicate-isolation/distinct-context outcomes without auto-destroying potentially foreign state. Keep recovery terminal until separate reconciliation is designed.

Additional exact-current Browser Session prerequisite from #315 98a28db0ac95972419906f229badf35c4f5fa0d6, review 5165103727: ownership recovery and transport liveness are currently collapsed in one enum in a way that drops a later real failure. After an uncertain create or unproven destroy moves the aggregate to RecoveryRequired, record_transport_loss() returns false solely because the state is no longer Active; the existing destroy-failure test even codifies that result. A subsequent real browser/WebDriver transport loss is therefore indistinguishable from an idempotent duplicate report. Recovery planning needs the distinction because a recovery-required aggregate with a live transport may still perform a separately authorized reconciliation/attestation path, while the same unresolved ownership followed by transport loss cannot use that connection.

Required hostile RED before #315/#313 adoption: enter RecoveryRequired, then lose transport; retain both unresolved ownership/cleanup evidence and the new transport-loss fact, reject all normal authority, and make only subsequent duplicate transport-loss reports idempotent. Prefer orthogonal transport-liveness and ownership/recovery state (or an explicit combined evidence model); merely overwriting RecoveryRequired with TransportLost would erase the cleanup/recovery identity required by review 5164398667.

#315 exact 98a28db0ac95972419906f229badf35c4f5fa0d6 has an additional sequential-incarnation prerequisite in review 5165358933. The current DisposableIsolationId contract proves non-aliasing only while a boundary is live. BrowserSession::start can reuse the external session id and restarts epoch at 1, while the authority tuple is session + isolation + browsing context + epoch. Therefore a later aggregate can become structurally indistinguishable from a retained stale authority if the remote/adapter reuses the same user-context/isolation string after the prior boundary was removed. The W3C 9 September BiDi text defines the user-context id as a unique string set at creation and resolves it through the current user-context set; it does not supply the historical generation/non-reuse guarantee OriginWeave would need to treat that string as a durable capability generation.

Required hostile RED before #315/#313 adoption: A creates (S,U,C,1), proves destruction and ends; B later starts at the same S, receives the same U/C, reaches local epoch 1, and must reject A's retained authority before any adapter I/O while accepting B's new authority. Carry a non-reusable lifecycle incarnation / verified browser generation through both authority validation and adapter lifecycle mapping; an aggregate-only nonce that does not reach the port is insufficient. Preserve the existing lossless recovery-evidence and orthogonal transport-liveness prerequisites.

Current #315 repair head is ab04f9522e97e1ecd6d914c48cb6f77f087eac3b on #313 base 6486e916dceb4ab5f33f7b390cd76fd4673d6007. The observed exact RED at 98a28db... was a real repository-contract drift: UML had intentionally moved to phase-specific DisposableContextDestroyError / cleanup unproven, while tests/test_browser_session_lifecycle_contract.py still required the obsolete destroy fails / cleanup unproven. The minimum causal repair changes only that assertion. Exact CI 34463908909 now has Rust contracts GREEN: Python repository contracts, canonical formatting, locked tests, strict Clippy, and rustdoc/API docs all pass. The first Production coverage attempt was cancelled by this run's Ready→Draft transition while installing pinned cargo-llvm-cov; it was not a source failure. Only that cancelled coverage job was rerun, and attempt 2 is executing on the unchanged exact head.

#315 is intentionally Draft and its body now names the remaining merge blockers: (1) lossless recovery identity for uncertain partial creation and duplicate adapter output, (2) transport liveness orthogonal to unresolved ownership/recovery evidence, and (3) sequential incarnation/ABA safety when a later aggregate reuses external session/user-context/browsing-context/local-epoch values. No #313 adoption or Browser Session→BiDi ACL opening is permitted until hostile RED→exact-head GREEN closes those invariants.

Exact-current verification settled GREEN for the concrete contract repair. On ab04f9522e97e1ecd6d914c48cb6f77f087eac3b, CI 34463908909 attempt 2 has Rust contracts 102828400972 SUCCESS and Production coverage 102828399476 SUCCESS through exact coverage enforcement. The first coverage job cancellation was caused by the Ready→Draft transition during pinned cargo-llvm-cov installation; the targeted unchanged-head rerun succeeded, so this is not an Actions/source RCA. #315 stays Draft because the three deeper Browser Session invariants already recorded here remain unresolved; no adoption into #313 follows from this repository GREEN alone.

Writer lease RELEASED for this run at #315 exact ab04f9522e97e1ecd6d914c48cb6f77f087eac3b. The branch is left Draft with repository GREEN and the remaining recovery/transport/incarnation prerequisites explicitly preserved. No merge, force update, workflow/ruleset/secret change, sandbox weakening, tag, or release was performed.

Writer lease ACTIVE — continuing #315 from exact ab04f9522e97e1ecd6d914c48cb6f77f087eac3b on #313 base 6486e916dceb4ab5f33f7b390cd76fd4673d6007. Scope: hostile RED for the remaining Browser Session invariants (lossless recovery identity, transport-liveness orthogonality, sequential incarnation/ABA) → minimum domain/port repair → exact-head repository verification → ordinary adoption only if all gates are satisfied. I will not mutate #229/#299, .github/**, rulesets/secrets, provider/model routing, sandbox policy, or use force/destructive restacks.

Exact-current reviewer handoff for active #315 writer: head 110eb33a6d368be977a0c37e49556af976ca09f6, review 5166529548. CI 34470987805 has Rust contracts GREEN but exact Production coverage RED at 862/865 regions (99.6532%); artifact 10149551238, digest sha256:6078f1b1f935a7e1e18f5b796be029c6770b7b02654440bf30517c00fb76916e. The three uncovered regions are lib.rs line 304 (BrowserSession::start allocator-error edge), line 435 (advance_context_epoch epoch-exhaustion edge), and line 439 (structurally unreachable second get_mut error after prior ownership proof). Please close by reachable hostile coverage + causal refactor, not coverage exclusion/global-static race. The recovery-identity, orthogonal transport-loss, and sequential-incarnation repairs in this head otherwise match the recorded invariants; no predecessor GREEN or #313 adoption follows until a fresh exact head reaches 100%.

PR-state repair note for the same active writer lane: #315 is live draft=false/Ready at exact 110eb33a6d368be977a0c37e49556af976ca09f6, while its own body still says it is Draft and exact Production coverage is terminal RED. I am not toggling PR state from the reviewer lane while lease 5617639353 is ACTIVE, because that can cancel/restart your current verification generation. After the causal coverage fix/current-head run is settled, keep the PR Draft unless every stated adoption gate is actually satisfied; do not leave a RED head Ready merely to preserve CI admission.

Writer lease RECOVERED/ACTIVE — prior lease 5617639353 started 2026-09-10 20:02 KST and has no matching RELEASE; the owned branch has remained exact 110eb33a6d368be977a0c37e49556af976ca09f6, and its CI 34470987805 has been terminal since 20:24 KST. I am treating that lease as an orphaned predecessor run rather than concurrent work and adopting its exact head without force/destructive restack. Scope for this lease is only the verified coverage RED already handed off in review 5166529548: make incarnation-exhaustion deterministic through the same production allocator path, cover active-context epoch exhaustion, remove the structurally unreachable second context lookup, then require a fresh exact-head repository GREEN. #229/#299, .github/**, rulesets/secrets, provider/model routing, sandbox policy remain untouched.

#318 exact 97b81ea5b228f43f370d48cdb549391e68555d47 adds an acceptance gap for ABA-style raw browsing-context reuse after proven destruction. Required invariant: raw BrowsingContextId equality is not ownership-generation identity. pending(old X) -> proven destroy(X) -> recreate raw X with newer aggregate-issued BrowserContextEpoch -> pending(new X) must reject old settlement/Aborted/Failed witness and retained old presentation authority as non-mutating AuthorityMismatch/zero-I/O; only the recreated generation's current witness may reach terminal and enable one explicit re-establishment. This should remain in #312 acceptance/owner planning until #317 production implements exact (incarnation, context, context_epoch) generation validation and #316 preserves matching remote correlation.

Navigation-authority acceptance update from #318 exact 69fbe26a308d315f6366b13cbb8b54c1274797be: refine invariant 3 so WebDriver BiDi browsingContext.navigationCommitted is treated as non-authorizing progress, not lifecycle completion. W3C WD 2026-09-09 await a navigation keeps ordinary navigation pending after start and waits separately for committed/interactive/complete readiness; fragment-only navigation is the early complete path. Browser Session must therefore keep the pre-navigation presentation authority revoked at commit, preserve the same opaque pending witness without epoch/recovery mutation, and permit that witness to later reach either complete-positive settlement (load or complete fragmentNavigated) or Aborted/Failed. Only the later terminal outcome may make explicit re-establishment eligible. Add this to the real Chromium acceptance sequence before considering navigation invalidation/re-establishment implemented.

Current Browser Session owner follow-up from #317 exact c4eddf8a7096e9199e1d47b7fc8ecbdf848857f0: recovery handoff/dispatch is now distinct from recovery completion, and the latter is still missing.

The current owner correctly moves unresolved custody into BoundBrowserSessionRecovery<P>, preserves the exact consumed adapter, blocks ordinary lifecycle/presentation methods, and routes only RecoveryContextOperationPort operations. It also correctly keeps RecoveryRequired and both evidence ledgers unchanged after an adapter Ok; command success is not proof. ADR 0116 explicitly says a separately reviewed proof-bearing transition is required before uncertainty can be cleared, but no such Browser Session transition exists yet.

Acceptance to add under this issue before #316 adoption: after an unproven destroy or uncertain create enters recovery custody, a protocol owner may perform purpose-bounded recovery I/O, independently qualify browser evidence, then present only an opaque/exact-fact settlement proof back to Browser Session. Settlement must consume only the matching recovery fact/ownership generation; stale/replayed/cross-incarnation/cross-context proof fails before mutation; sibling evidence is preserved; and no ordinary create/presentation/navigation authority is resurrected. A command ACK or generic adapter Ok must remain non-settling. BiDi proof qualification and remote tuple/liveness semantics stay in #316; this issue/#317 owns the protocol-agnostic lifecycle settlement boundary.

Current Browser Session owner progress:

#317 is exact 0154f19cf5fca89c9e27d8c5d135482aa910553e and Draft. Test-first 738ec7d9a6635a8b4b0b9324026c2f0b433b9c77 adds recovery_exact_fact_settlement.rs; current head adds docs/doctoring/browser-session-recovery-settlement.md. The RED requires stale/replayed and cross-session/incarnation recovery facts to fail before proof-verification I/O, a failed/wrong proof to leave custody unchanged, settlement of one fact to preserve sibling uncertainty, identity-oriented and create-attempt recovery ledgers to retire independently, and full reconciliation to reach a terminal closed state without reviving ordinary create/presentation/navigation authority.

This keeps the issue's original invariant intact: browser/protocol command ACK is not destruction or restoration proof. Browser Session owns exact fact consumption and state transition; #316 remains the owner of WebDriver BiDi-specific event/tuple/liveness qualification that can supply independently reviewed proof to that boundary.

Dependent acceptance stack is ordinary non-force restacked: #318 7fb4180e455a5c7fe3c038401ffc0ac51d10523f on #317, then #321 d295b98d8dc83c7aa1a92a326b42e422e24eb565 on #318. A Ready probe on the same #317 exact head created CI 35058285003, but both native jobs remained pre-runner (runner_id=0, steps=[]) and were cancelled when the known structural-RED branch returned to Draft. No hosted compile RED or executable GREEN is claimed.

Current Browser Session owner checkpoint superseding prior recovery-settlement RED notes: #317 exact 71666b207c82e3a00d8c3bc71c27769100cb1256 now implements the protocol-agnostic proof-bearing exact-fact settlement boundary. Recovery custody issues opaque revision-bound facts, rejects foreign/stale/out-of-range facts before verifier I/O, verifies proof through the exact retained adapter, retires only the selected recovery/create-attempt fact, preserves siblings, and reaches Ended only when both ledgers plus uncertain hot ownership are empty. Owned-context retirement is restricted to exact Uncertain handles represented by UnprovenDestruction, RecoveryRequiredOwnedHandle, or TransportLossOwnedHandle; candidate/partial-create evidence cannot consume an accepted same-valued owner. No ordinary create/navigation/presentation authority is resurrected.

Static exact-head review found this path sound and git diff --check clean. Executable acceptance is still open: CI 35062705932 has Production coverage 104686219873 and Rust contracts 104686220043 queued without steps. Current non-force stack is #317 71666b... → #318 2bab48eecad3d5ba0931299f9493ee9b0366d179 (48-path navigation acceptance, behind_by=0) → #321 90651c112b9d36af87865adf74375526e21accc3 (8-path ABA acceptance, behind_by=0). Keep issue #312 open until runner-backed gates plus #318/#321 and real pinned-Chromium recovery/navigation post-condition acceptance complete.

Browser Session owner update: #317 current exact f01b68fbb9201ca097a7dcd4cf8af873b4b8e99f closes a follow-on capability gap in recovery custody. Before this repair, final exact-fact settlement could transition the aggregate to Ended while BoundBrowserSessionRecovery<P>::execute_recovery_context_operation remained callable through the retained adapter. The new hostile fixture proves recovery I/O is available while uncertainty exists, then requires RecoveryClosed and zero adapter calls after terminal settlement. Production now checks RecoveryRequired | TransportLost before dispatch. #318/#321 were ordinary non-force restacked with exact parent blobs preserved (e74fa639... / 653b5d941...). Executable GREEN is still pending: #317 CI 35066676349, jobs 104698408266 / 104698408542 remain pre-runner queued at the latest check. BiDi proof/event semantics remain #316-owned.

#317 current exact 49d7419fe25c4d22d11ad928286549b4487ecf82 found and repaired a recovery least-authority gap before re-admission. Prior execute_recovery_context_operation(operation) needed only aggregate recovery state and exposed both complete recovery ledgers to the retained adapter. Current source now requires one Browser Session-issued RecoveryFact, validates exact session/incarnation/revision/address before adapter I/O, rejects foreign/stale facts pre-I/O, and puts only the selected identity-oriented or create-attempt fact in RecoveryContextOperationRequest. Command result remains non-settling; proof-bearing settle_recovery_fact remains separate; final settlement still closes generic recovery I/O with RecoveryClosed.

Test-first/source evidence: new recovery_operation_exact_fact_scope.rs, updated same-adapter/terminal fixtures, repository contract, ADR 0116, lifecycle TRACEABILITY/UML, recovery doctoring. #317 is intentionally Draft until exact-head repository execution is observed; this comment is not GREEN/shipment evidence.

Dependent tree-provenance was repaired non-force as well: #318 521892445f699b73277f15cc4cfba96d2f5b342b compares to current #317 with merge base=current parent, behind_by=0, exactly 48 child paths; #321 321a4ec1bdb45a716a333937fcbca04704688976 compares to current #318 with merge base=current parent, behind_by=0, exactly 8 child paths. #316 remains the BiDi proof/tuple/liveness owner and is not restacked until the Browser Session prerequisite is executable GREEN.

Browser Session owner repair: #317 exact afd1b70102b8f19482441218a54d4f90bc03fa39 keeps the 49d7419... exact-fact recovery production/test/ADR tree but removes an unrelated single-writer violation. docs/product-technical-gap-baseline.md had remained in #317 with stale live-status prose even though #238 is the canonical baseline owner; it is now restored exactly to the #229 blob and no longer appears in #317's effective 38-path delta.

Dependent branches were non-force adopted and tree-repaired rather than relying on ancestry alone: #318 83b0d26be59bded622fec33d4f439c9ca9a61588 is behind_by=0 with exactly 48 navigation-acceptance paths, and #321 dcaf2ee57a97b03318855605fabbc5b61c7abbcc is behind_by=0 with exactly 8 ABA/sibling-recreation paths; the baseline file is absent from both effective child deltas. #316 remains the BiDi proof/tuple/liveness owner and is still not restacked before Browser Session executable GREEN.

Current #317 CI 35078281589 remains pre-runner queued (Production coverage 104735789290, Rust contracts 104735789537, no steps), so this is source/provenance repair evidence, not GREEN or shipped behavior.

Browser Session owner update — current #317 exact 91ea230874dcec51f869c7198461760a3fe2f8ca is back to Draft after a fresh diagnostics-boundary finding.

BoundBrowserSession<P> already redacts its Debug, but the public read-only projection browser_session() -> &BrowserSession returns a type with derived Debug. Because the aggregate contains exact owned-context and recovery records, ordinary downstream formatting can disclose remote disposable-isolation/recovery identities even though the wrapper itself is redacted.

Test-first hostile fixture crates/originweave-browser-session/tests/browser_session_view_debug_redaction.rs now creates sentinel isolation browser-session-debug-secret-isolation, proves bound-wrapper formatting omits it, and requires the read-only Browser Session view to omit it as well. Current source is expected to fail that final assertion; Draft CI 35082882584 is policy-skipped, so this is source-level RED, not executed RED/GREEN.

Minimal owner repair remains in #317: replace derived Debug on BrowserSession with an inert/manual redacted projection that does not format exact contexts, recovery evidence, create-attempt evidence, or remote lifecycle identities. Do not weaken or delete internal recovery evidence.

Stack was non-force adopted: #317 91ea230... -> #318 5cf3e42b33421b2d6b0cf4138005a23f0b87edf9 (48 child paths, behind 0) -> #321 a257ac33c055372c5097741b4b62a90239ff2ab5 (8 child paths, behind 0). #316 remains un-restacked and retains WebDriver BiDi proof/tuple/liveness ownership until #317 earns executable current-head GREEN.

Browser Session current handoff: #317 exact 9f5d0687d860306909385175c39edc8bc9297609 repairs the public diagnostics bypass discovered on predecessor 91ea230.... BrowserSession no longer derives recursive Debug; it now renders only session/incarnation/state/transport flag and bounded counts, while exact owned-context/recovery/create-attempt identities remain internal. The hostile sentinel fixture is unchanged.

Dependent stack was ordinary non-force adopted with tree preservation: #318 5093e6bc4693c5b037f6908bf97267379a8bbb6d retains exactly 48 navigation-acceptance paths over current #317, and #321 78270fef08c55f494ee2e994a8112323974447ac retains exactly 8 ABA/sibling-recreation paths over current #318. #316 remains un-restacked and continues to own BiDi tuple/event/liveness/proof qualification.

#317 admission CI is run 35085599921; Production coverage 104759543405 and Rust contracts 104759543662 were still queued with no runner/steps at last read. No executable GREEN or merge claim yet.

2026-09-16 standards-provenance repair on Browser Session owner lane: authoritative W3C TR now publishes WebDriver BiDi WD 14 Sep 2026 (WD-webdriver-bidi-20260914), with 9 Sep as previous and Editor's Draft separate. #317 exact is now c9ebac3ebe99f5d36e9cd7333b9d831416f8be7d; added a focused publication-trace repository contract and currentized ADR 0114 + lifecycle TRACEABILITY without changing production Rust/runtime compatibility. Dependent stack was non-force adopted with tree preservation: #318 92c270c7cfcbc5d149e977279c4b9d7263e87c6f (48-path child delta), #321 b7dc6361bbe8b07b465d33a8f6ab1cfcc04283d1 (8-path child delta). #317 is Ready only for admission; current CI 35088483023 remains queued, so no executable GREEN or shipment claim.

Superseding the earlier standards-provenance handoff after the contract-strengthening follow-up: Browser Session owner #317 is now exact 747770246346baf6491586005346bfeff45b5af0. The W3C TR repair remains documentation/test-only; production Rust and Chromium/runtime qualification did not change. The focused repository contract now checks semantic roles rather than token presence: 14 Sep 2026 is current published WD, 9 Sep is previous, Editor's Draft is separate, and runtime compatibility is a separate provenance axis. Tree-current dependent stack is #318 983fa652180e47e479c99b8903755f1fd60f0746 (exact parent merge base, behind_by=0, 48 child paths) → #321 9d3c51e7ff66c952dba203a04704e53df78d2b0e (exact parent merge base, behind_by=0, 8 child paths). #317 CI 35088756166, Rust contracts 104769771617, Production coverage 104769771899 remain queued with no runner/steps, so no executable GREEN is claimed.

2026-09-17 Browser Session owner checkpoint: canonical originweave-bidi parent #229 remains exact df48a4c8995c741978e669472a91ae89e9b09dee; fresh W3C publication history still has 16 Sep 2026 as latest published WebDriver BiDi WD, 14 Sep as previous, and the runtime-qualified pin remains 3 Sep. #229 CI/Security/Semgrep/CodeQL remain queued, so parent executable admission has not occurred.

#317 is now exact 54d7367ac8b02e7aba0585d6d4f902228d419d7b and remains Draft. The single-writer repair now covers ADR 0114, lifecycle TRACEABILITY, and navigation TRACEABILITY: all consume docs/traceability/webdriver-bidi-publication-current.md and no longer own dated/current/latest/previous Working Draft currentness. A wider repository-contract sweep also found and repaired a stale legacy assertion in tests/test_browser_session_lifecycle_contract.py that still required WD-webdriver-bidi-20260909; the focused publication contract now checks ADR + both Browser Session traces. Production Rust/runtime qualification is unchanged.

Exact current compare remains diverged from #229 at merge base 8dcacba..., ahead 164 / behind 6. Current Draft CI 35115139317 is completed/skipped, so this is structural/source repair, not executable repository GREEN. #318 983fa652180e47e479c99b8903755f1fd60f0746 and #321 9d3c51e7ff66c952dba203a04704e53df78d2b0e stay Draft with inherited #317 provenance explicitly marked stale until #229 earns admission → #317 ordinary non-force adoption → ordered child restack.

Current Browser Session review boundary has been refined against the canonical threat model and active successor code.

The source reachability reported on #229 is real: DisposableContextHandle::new(...) and cross-crate DisposableContextPort are public, so arbitrary Rust code already linked into the process can implement the port and return a fabricated handle. #317's bound-port ownership plus aggregate-issued create request/completion, attempt epoch and session incarnation prevent adapter swapping/replay/ABA classes, but request/completion correlation is not adapter authentication.

The security classification is narrower than the original CWE wording implied. docs/THREAT_MODEL.md places the Rust control plane and privileged Chromium/browser integration inside the trusted computing base, and originweave-browser-session is an internal publish = false crate. Hostile linked Rust is therefore a supply-chain/trusted-code compromise, not an untrusted web actor that a nonce or opaque request handed to the same implementation can isolate. Sealing the trait in Browser Session would also break the separate canonical adapter crate; a generic public marker would be equally forgeable.

Canonical repair lane #317 is now exact 1b901bc1c0b34edd62054ee10dfc679a149e7b83 and remains Draft. It added test-first repository contract tests/test_browser_session_trusted_adapter_boundary.py plus docs/traceability/browser-session-trusted-adapter-boundary.md. The supported-product acceptance is now: Browser Session stays internal/unpublished; privileged lifecycle adapters are explicit TCB components; production DisposableContextPort implementations are allowlisted review surfaces; and no production source outside the Browser Session owner may silently introduce caller-selected .bind_lifecycle_port(...) composition. Test doubles remain test-only and grant no shipped product capability.

The contract is structurally satisfied on the current tree, but exact CI 35156922954 is Draft-skipped, so no executable GREEN is claimed. #317 still must ordinary/non-force inherit every valid #229 delta, reconcile root ARCHITECTURE.md so BrowserSessionIncarnation is explicit in PresentationMutationAuthority/sequential-ABA semantics, and obtain fresh exact-head repository/security review. Keep both #229 review threads unresolved until independent review accepts this TCB/composition classification and the repaired successor earns executable evidence. Real pinned-Chromium acceptance remains downstream.

Fresh Browser Session owner-path finding on #317, exact 706bc9e459790a39dea91733a2b168e99de2344b:

The trusted-adapter policy itself did not change, but its repository enforcement had real false-negative syntax/layout paths. The original contract recognized only literal impl DisposableContextPort for ... and .bind_lifecycle_port(. Test-first repairs now cover qualified/aliased trait names, UFCS/whitespace binding, cross-file trait aliases, and Cargo direct/package-alias/table dependency forms. Production crate dependencies on originweave-browser-session are now an explicit allowlisted review surface in addition to source references; the only reserved future external owner remains originweave-bidi / #316. Exact commits: RED→GREEN 100c004...→7b2334b..., cross-file RED→dependency gate 6ce9c1f...→cb9fb54..., Cargo alias RED→GREEN 1e46b30...→b24b9be..., traceability 706bc9e....

This changes no Rust runtime authority semantics and does not claim hostile linked Rust is sandboxed; it closes enforcement gaps around the existing TCB/supply-chain boundary. #317 remains Draft and its current CI is policy-skipped, so this is source/contract evidence only, not exact-head repository GREEN. Parent #229 750821a3... remains the prerequisite for runner-backed evidence and later ordinary ancestry reconciliation.

Navigation Menu

Repository navigation

[Browser Session] Mint presentation mutation authority from owned lifecycle #312

Buyer / DDD gap

Ubiquitous language and aggregate boundary

Core invariants

Test-first acceptance

Real Chromium acceptance

Integration order

Documentation / decision record

Non-goals

88 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[Browser Session] Mint presentation mutation authority from owned lifecycle #312

Description

Buyer / DDD gap

Ubiquitous language and aggregate boundary

Core invariants

Test-first acceptance

Real Chromium acceptance

Integration order

Documentation / decision record

Non-goals

Activity

seonghobae commented on Sep 10, 2026

seonghobae commented on Sep 10, 2026

seonghobae commented on Sep 10, 2026

seonghobae commented on Sep 10, 2026

seonghobae commented on Sep 10, 2026

seonghobae commented on Sep 10, 2026

seonghobae commented on Sep 10, 2026

seonghobae commented on Sep 10, 2026

seonghobae commented on Sep 10, 2026

seonghobae commented on Sep 10, 2026

seonghobae commented on Sep 10, 2026

seonghobae commented on Sep 10, 2026

seonghobae commented on Sep 10, 2026

seonghobae commented on Sep 10, 2026

seonghobae commented on Sep 10, 2026

88 remaining items

seonghobae commented on Sep 13, 2026

seonghobae commented on Sep 13, 2026

seonghobae commented on Sep 16, 2026

seonghobae commented on Sep 16, 2026

seonghobae commented on Sep 16, 2026

seonghobae commented on Sep 16, 2026

seonghobae commented on Sep 16, 2026

seonghobae commented on Sep 16, 2026

seonghobae commented on Sep 16, 2026

seonghobae commented on Sep 16, 2026

seonghobae commented on Sep 16, 2026

seonghobae commented on Sep 16, 2026

seonghobae commented on Sep 16, 2026

seonghobae commented on Sep 16, 2026

seonghobae commented on Sep 17, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions