feat(browser): bind presentation identity to versioned Chromium emulation evidence

[seonghobae]

Buyer-visible gap

originweave-fingerprint owns pure presentation identity. OriginWeave still needs browser-domain proof that an admitted profile is actually applied before page script, observed from the same version-qualified Chromium context, survives required failure cases, and is safely restored or destroyed. Protocol acknowledgement alone is not success. MCP/driver transports, LLMs and sibling owners must not become deterministic browser-policy or presentation-truth owners.

Current dependency authority — 23 September 2026 KST

Canonical presentation/WebDriver BiDi parent #229 is exact 60318092c410111924415b3e20ee3f4186e6472a, open / Draft / mergeable on protected main@87c4daa1830bac5a5228b6036752ad5633232085. W3C's live WebDriver BiDi publication history currently lists 16 September 2026, 14 September 2026, 9 September 2026, then 3 September 2026 Working Drafts. Publication freshness and runtime qualification remain separate authorities: OriginWeave's independently qualified adapter pin remains 3 September 2026 until dedicated schema/browser compatibility evidence proves a newer revision. Current #229 ordinary-forward repair lineage currentizes the publication receipt/ADR and removes prose-label coupling from the currentness oracle. Exact-head CI 35713817985 is Draft-skipped; SAST 35713817883 and Security 35713817945 are terminal SUCCESS. CodeQL 35713817902 remains nonterminal: Detect 106700519278 is SUCCESS, its three compatibility jobs executed and failed closed only because no authenticated terminal current-head verdict existed, and coordinator 106826100321 remains pre-step queued with runner_id=0 and steps=[]. Fresh #229 review inspection has 0 unresolved threads but no qualifying current-head APPROVED review. Predecessor GREEN/review evidence does not transfer.

Browser Session successor #317 is exact 70cc9d8ab9cbb79e3f7c8635ba5c4bec67d80b73, open / Draft / non-mergeable. Fresh GitHub compare from current #229 is ahead 634 / behind 31 / diverged at merge base 8dcacbaebf2a6f02c5bbda8e8d6cc8bce474b693. Reconciliation must be ordinary/non-force, preserve all 634 valid child deltas, and adopt/adapt current #229 standards truth without duplicating volatile publication metadata in Browser Session domain documents.

The downstream Browser Session chain remains #318 exact 983fa652180e47e479c99b8903755f1fd60f0746 → #321 exact 9d3c51e7ff66c952dba203a04704e53df78d2b0e → protocol/ACL owner #316 exact 8ca6c5a190d9ad2b4c7843d440e91f6070d681c2. These are Draft generations on predecessor ancestry. Mergeability on an individual child is topology only, not acceptance.

Issue #212 remains the canonical owner for the volatile central workflow/sandbox/admission chain. Canonical AnyIO owner .github#2278@8a5251bf409fe84b3dd0cba1e48992f5b8d9eda5 carries the one-file AnyIO 4.14.0 → 4.14.2 repair; SAST, Python Security, and Security Scan are GREEN while CodeQL remains fail-closed on central verdict publication and current-head approval is missing. Canonical trusted Strix owner .github#2291@1794626af3473ef23b9c2e678c3f06fd6c11636f has Runtime Quality/SAST/Security GREEN, Python Security failing only at pip-audit while inheriting protected AnyIO 4.14.0, and nonterminal CodeQL. OriginWeave must not copy either owner repair or weaken browser sandboxing.

The former 21 September authority named #229 3ec6326b... and a 634-ahead/25-behind relationship. Earlier history named #229 c7b7b0d..., #317 5dc7592..., and 562-ahead/12-behind. Those values are historical only and no longer define dependency authority.

Browser acceptance invariants

1. originweave-fingerprint remains the pure profile/value owner; browser adapters depend inward on it.
2. Capability claims are explicit per admitted browser/protocol revision; partial required surfaces fail closed.
3. Apply occurs before the target page-script/navigation epoch; navigation/renderer replacement invalidates evidence until Browser Session re-establishes authority.
4. ACK is not evidence. Read page-visible post-conditions from the exact owned context.
5. Apply/cleanup authority is symmetric. Reusable contexts require exact predecessor restoration; otherwise prove destruction of a Browser Session-owned disposable context/profile.
6. BrowserSessionIncarnation participates in authorization validation and sequential-ABA separation.
7. Unsupported revision/mode, partial application, command error, observed mismatch, renderer/process failure or cleanup ambiguity is non-passing.
8. Presentation consistency is privacy/compatibility behavior, not authorization to bypass CAPTCHA, consent or access control.

Real Chromium lane

PR #299 remains the browser-observed acceptance lane. Native repository CI does not substitute for browser success. Its pinned Chrome/ChromeDriver 150.0.7871.129 generation is immutable historical reproducibility evidence and remains browser RED because session creation never reached the page-observed presentation/interaction/reset post-conditions.

Current-Stable Chromium qualification is a separate versioned evidence generation owned through #212 and the canonical central MV3 workflow. Do not rewrite the Chrome 150 receipt in place, infer a matching Chrome-for-Testing artifact without an immutable asset/digest receipt, copy the central reusable workflow, or use --no-sandbox.

A passing pinned-browser run requires all three trials to prove ambient-distinct baseline → presentation apply → page-observed target → browser-computed semantics → native clear/type/click → accepted outcome → URL stability → explicit presentation reset → page-observed original baseline → WebDriver session/profile cleanup.

Delivery order

Required order is owner-first and acyclic:

#212 central dependency/trusted-runtime/admission prerequisites reach causal GREEN and normal protected integration → current #229 executable native CI/CodeQL/current-review/ruleset acceptance on repaired standards authority, with exact SAST/Security already GREEN → ordinary/non-force #229→#317 reconciliation preserving current parent truth + all 634 valid child deltas → fresh #317 executable repository/security/whole-current-head and owned-quality closure → #318 → #321 → #316 ordered non-force restacks → canonical central MV3 workflow acceptance/immutable consumer pin → #299 replay with actual session creation and complete page-observed post-conditions.

Keep this issue open until the exact pinned-Chromium path proves the complete sequence and reaches protected main through normal review and required workflows. No self-approval, bypass, force push, destructive rebase, gate weakening, workflow copy, source-neutral wake commit, merge, tag, release or publication is authorized here.

[seonghobae]

Writer lease ACQUIRED — bounded #292 slice only. Exact prerequisite is #229 024f63690cf05cfe6f0d4a430f0e18ea8fd2c4d6; protected main is 87c4daa1830bac5a5228b6036752ad5633232085. Scope: introduce the smallest test-first, version-pinned WebDriver BiDi presentation-emulation capability boundary without changing originweave-fingerprint, workflows, rulesets, secrets, or browser/policy authority. First acceptance is fail-closed: the 2026-08-18 WebDriver BiDi capability set must not produce a complete presentation witness because required HardwareConcurrency (and the full Chromium platform/UA-CH surface) is not standard-BiDi authority. No production repair will be added until the exact test-only regression is observed RED.

[seonghobae]

Fresh authoritative re-check on 2026-09-07 supersedes the earlier correction in this comment. The canonical W3C latest-published WebDriver BiDi URL now resolves to the 3 September 2026 Working Draft (https://www.w3.org/TR/2026/WD-webdriver-bidi-20260903/), and that document lists 1 September 2026 as its previous version. The 18 August publication listing I previously relied on was stale relative to the canonical latest-published document. #292/#293 must therefore either update their current-standard traceability to 3 Sep or explicitly declare 18 Aug as a compatibility pin and record the delta; do not call 18 Aug the latest published revision.

The capability/provenance finding remains valid against the 3 Sep draft. emulation.setScreenSettingsOverride still exposes only screenArea { width, height }, while #229's canonical PresentationSurface::Screen includes color depth. Standard BiDi therefore cannot certify the whole Screen surface without a version-pinned Chromium remainder and page-observed screen.colorDepth/screen.pixelDepth evidence. emulation.setLocaleOverride still accepts one locale, so ordered navigator.languages parity remains unproven without pinned-browser post-condition evidence.

Fresh #293 exact-head evidence is now also actionable: 0b0797c66f81f13fe72b709e2c1df0b6ec0026e8, CI 34095314936. Production coverage 101657573334 passed, but Rust contracts 101657573294 failed after exact checkout in the Python repository contract because root Cargo.toml includes the new reusable crates/originweave-bidi member and tests/test_repository_contract.py still omits it. Rust fmt/tests/Clippy/rustdoc were skipped after that failure. #293 has been returned to Draft. Under this existing #292 writer lease, repair order should be: preserve the hosted RED; update the repository workspace contract; add/adjust a test that prevents whole Screen/Languages canonical-surface certification without their complete semantics; then make the smallest production capability-map/traceability change and regenerate exact-head evidence. Do not create a competing source writer.

[seonghobae]

Writer lease RELEASED — lease arbitration repair. Fresh timestamp comparison shows repository-wide sole source/docs lease #255 comment 5565646422 was acquired at 2026-09-07T05:45:14Z, before this bounded #292 lease 5566459889 at 2026-09-07T07:06:41Z. The later bounded lease therefore must not coexist as source authority.

Before that ordering defect was detected, two ordinary non-force commits were already published on the separate #293 branch: ba584c7f73becb03ca29ba79b8b705cf23e47050 registers the already-present originweave-bidi workspace member in the repository contract, and test-only 9f11b0c8268890b0620c94b6975d461f67511afa encodes the 3 Sep 2026 BiDi revision plus fail-closed complete-surface expectations. Preserve those deltas; do not force-rewrite, close, or pretend they were unmade. Exact CI 34114834059 for 9f11b0c8... skipped both jobs while Draft, so the new semantic assertions are not an observed RED and no production capability-map repair is authorized yet.

No further #292/#293 repository source or docs mutation will occur under this released lease. After the older #255 sole writer publishes and releases, the next writer must read the intervening #293 deltas, verify path overlap/non-overlap, observe the new RED through a policy-compliant execution path, then continue the minimal repair. Issue/PR state remains Draft/open; this is coordination repair, not closure or supersession.

[seonghobae]

Standards/cleanup refinement for the eventual real-Chromium GREEN: the 3 September 2026 WebDriver BiDi WD explicitly states that the remote end's device-pixel-ratio override map is not cleared when the final WebDriver session ends; DPR overrides can therefore outlive a session. The same spec exposes browsingContext.setViewport with devicePixelRatio: null, whose algorithm removes the override for the affected navigable(s). See §7.3.1/§7.3.3.12: https://www.w3.org/TR/webdriver-bidi/#browsing-context and https://www.w3.org/TR/webdriver-bidi/#command-browsingContext-setViewport.

This makes the generic cleanup acceptance in this issue materially stronger: do not treat session.end, context destruction, or transport teardown as proof that presentation state has been removed. The realistic browser lifecycle test should apply a deliberately non-default DPR, prove the page-observed value, end/replace the WebDriver session as the product actually does, then prove either (a) OriginWeave explicitly resets the DPR override to null on every still-addressable owned navigable before releasing the browser/user-context, or (b) the entire owned browser/profile boundary is destroyed and a fresh boundary cannot observe the prior DPR. A reset ACK alone is insufficient; observe the post-reset/fresh-boundary value. Crash/timeout on this cleanup path remains non-passing and must not release a reusable browser boundary as clean.

This is not a request to widen PR #293's current test-only capability-map slice or to move lifecycle authority into the BiDi adapter. It is a #292 application/recovery invariant that should be carried into the typed browser-session owner and realistic E2E once the current sole repository writer releases.

[seonghobae]

Standards/provenance correction after fresh W3C publication-index and exact upstream-history verification. The current W3C Standards/Drafts index and Browser Testing and Tools WG publications page both list WebDriver BiDi Working Draft — 18 August 2026 as the latest published Working Draft. The existing issue text/comment that calls 3 September 2026 the canonical latest-published Working Draft is therefore stale; 3 September material must not be represented under a published-WD provenance contract unless W3C actually publishes such a snapshot.

For #293/#292, keep the specification identity immutable and explicit rather than making a release adapter “track current”. If the owner contract is the published Working Draft, pin the dated W3C publication identity for 18 August 2026 and, for doctoring/reproducibility, record the exact upstream source commit/digest used to derive capabilities. This matters because upstream w3c/webdriver-bidi changed the media-feature CDDL on 18 August itself at signed commit 1e5e36c43adbe24f2a4052c2ec091635c006c352 (list media features (#1149)): that snapshot explicitly includes prefers-reduced-motion. A bare date alone is weaker provenance than the immutable document/source identity.

The coarse-surface findings remain version-coherent against that exact 18-August source: emulation.ScreenArea is only { width, height }, so standard BiDi alone cannot certify #229 PresentationSurface::Screen if the canonical surface also requires color depth; emulation.setLocaleOverride accepts one locale string/null, so it cannot by itself certify an ordered language-preference vector. ReducedMotion, however, is represented by the 18-August media-feature work and should not be removed on the basis of the earlier stale /TR/ rendering.

Repair order when the active repository-wide source lease is released: first correct the test/body provenance without manufacturing a 3-September published-WD RED; then derive complete-surface assertions from the immutable 18-August snapshot; only after a policy-compliant RED is observed should production capability code change. Real pinned-Chromium application and page-observed post-condition evidence remain the buyer-visible #292 acceptance boundary. This comment corrects standards evidence only; it does not reacquire the released #292 writer lease or authorize competing source/docs mutation.

[seonghobae]

Standards/provenance refresh from active adapter slice #293: exact #293 head is now f0a3b66a4ff3034d8a4e23e9b75ca2679fd0d3de. W3C's current publications index and WebDriver BiDi cover page identify 18 August 2026 as the latest published Working Draft, not 3 September. The false September assertion has been removed from #293; the adapter now retains 2026-08-18 as publication identity and records immutable upstream w3c/webdriver-bidi@1e5e36c43adbe24f2a4052c2ec091635c006c352 only as the same-day source snapshot used for media-feature doctoring, including prefers-reduced-motion.

The actual capability RED remains intentionally unfixed: current production still includes complete canonical Screen and Languages, while the test-first contract requires them absent because standard BiDi exposes only screen width/height and one locale rather than #229's complete color-depth/ordered-language invariants. Exact CI 34166151155 on f0a3b66... was skipped under Draft gating, so this is not an observed behavioral RED or GREEN and the production capability map must not advance yet. The issue body's September date is stale; use this correction and #293 current body/head as the current provenance checkpoint until the owner text is reconstructed safely.

[seonghobae]

Owner-path correction after a fresh canonical W3C re-read: issue #292’s body is correct and the later comment 5574070364 is not. As of 2026-09-08, https://www.w3.org/TR/webdriver-bidi/ identifies WebDriver BiDi Working Draft, 3 September 2026 as the latest published version, and W3C’s publication-history page lists 3 Sep → 1 Sep → 25 Aug → 24 Aug → 18 Aug. The 18-August-only conclusion came from stale/incomplete publication-index evidence and must not drive the adapter provenance.

This does not change the substantive bounded-context decision already recorded here. In the dated 3 Sep WD, emulation.ScreenArea remains width/height only; emulation.setLocaleOverride remains a single locale; and emulation.setMediaFeaturesOverride includes prefers-reduced-motion. Therefore complete Screen and ordered Languages remain partial/unsupported standard-BiDi surfaces, while ReducedMotion remains represented by the standard command set. The DPR cleanup invariant in comment 5572561945 also remains valid.

Current active #293 head f0a3b66a4ff3034d8a4e23e9b75ca2679fd0d3de regressed the publication constant/test/body to 2026-08-18 after the stale standards review; exact CI 34166151155 is terminal skipped, so that head has neither a provenance RED nor semantic GREEN. I have recorded the exact-head correction in review 5135689378. When the repository-wide source lease releases, preserve the intervening #293 history but restore the 3-Sep published-WD provenance first, keep the complete-surface RED (Screen/Languages absent, ReducedMotion present), observe it through a policy-compliant execution path, then make the minimal capability-map repair. Do not infer a 3-Sep upstream source SHA solely from commit date; the dated W3C TR itself is already immutable publication identity, and any auxiliary source-commit pin must be separately verified.

[seonghobae]

Current dependency evidence refresh (2026-09-08): PR #293 exact published head is 0c077445d73640a6299ea4d379faa4b0ab0226c2 (the body still references 9f11b0c…). #293 remains Draft; its central Rust/coverage checks are skipped while Draft, and live browser visual evidence is still unproven because the Edge diff tab rendered the older 2026-08-18 revision. The documented 3 September 2026 WebDriver BiDi boundary and explicit cleanup planner are present in the current PR, but complete Chromium page-observation acceptance remains open.

[seonghobae]

Fresh owner-path correction, 2026-09-08: the issue body’s “3 September 2026 Working Draft” publication identity is stale/incorrect. Current W3C authoritative publication surfaces agree that the latest published WebDriver BiDi Working Draft is 18 August 2026: the W3C Standards/Drafts index, the WebDriver BiDi series cover page, and the Browser Testing and Tools WG publications page all show 18 August. The 3 September document is the Editor’s Draft at w3c.github.io/webdriver-bidi/, which itself points to https://www.w3.org/TR/webdriver-bidi/ as the latest published version. The purported immutable dated TR https://www.w3.org/TR/2026/WD-webdriver-bidi-20260903/ is not supported by the current W3C publication inventory.

This changes provenance only, not the semantic capability conclusion: standard BiDi still does not prove OriginWeave’s complete Screen (dimensions + color depth) or ordered Languages, while Viewport, DPR, TimeZone and ReducedMotion remain the four complete admitted surfaces in #293. Exact #293 head 0c077445d73640a6299ea4d379faa4b0ab0226c2 currently pins the incorrect 3-Sep publication identity; formal COMMENT review 5138567735 records the minimal test-first repair. Its native CI 34195977205 is terminal skipped, so keep #293 Draft and do not transfer local predecessor GREEN.

[seonghobae]

Fresh #293 checkpoint: exact head 212a0ae2910cf62ba144db7cc0ff503e73d2f1cc now contains the test-first documentation contract for the already-known stale ARCHITECTURE.md / CHANGELOG.md / docs/doctoring.md references. The contract is deliberately RED against the current branch text: those documents must stop claiming 18 August as the published WD, cite the immutable 3 September dated TR, and describe timezone/media cleanup as well as viewport/DPR. Draft CI skips native execution, so no hosted RED/GREEN is claimed yet.

A separate cleanup-ownership finding is now recorded in #293 review 5139941850: W3C features: null unsets the target media-feature override configuration; it is not a selective inverse of only OriginWeave's prefers-reduced-motion write. Before #292 can claim reuse-safe cleanup, pinned Chromium must prove either an explicitly exclusive owned context/profile boundary (destroyed when restoration is not representable) or bounded snapshot/restore of prior media configuration. Seed an unrelated prior media override in the exact target and verify it survives/restores; ACK alone is not acceptance.

[seonghobae]

Current #293 checkpoint after review 5139941850: exact head is ef82e401030a67db52de34d9dc0ad9a42f059564 on #229 024f63690cf05cfe6f0d4a430f0e18ea8fd2c4d6, still Draft. The cleanup-authority defect is now narrowed at the adapter API boundary: generic plan_standard_presentation_cleanup plans only viewport/DPR and timezone reset; ResetMediaFeatures is reachable only through explicit caller-supplied ExclusivePresentationContext and plan_exclusive_presentation_media_cleanup. This prevents a reusable-context cleanup path from silently treating features: null as a selective inverse for prefers-reduced-motion.

This is not Browser Session ownership evidence. ExclusivePresentationContext is an attestation input; the adapter does not discover or mint exclusivity. The real pinned-Chromium acceptance remains: establish an actually exclusive disposable context/profile or restore complete pre-existing media state, apply reduced-motion, cleanup, then observe the relevant post-condition or destroy the owned boundary. ACK alone remains non-passing.

Exact native CI 34213770429 for ef82e401... completed skipped while Draft, so no hosted Rust/Python/Clippy/rustdoc/100%-coverage GREEN is claimed. The pre-existing documentation RED also remains: ARCHITECTURE.md, CHANGELOG.md, and docs/doctoring.md still need the 3 September 2026 published-WD and cleanup-authority wording repaired before #293 is documentation-complete.

[seonghobae]

#293 documentation checkpoint superseding the stale body subsection: exact head is now ef2630566fdfd3c044075316a971cdade82e740f on #229 024f63690cf05cfe6f0d4a430f0e18ea8fd2c4d6, still Draft. The test-first documentation RED is repaired in source: e71a4997... aligns ARCHITECTURE.md, c63339bb... aligns CHANGELOG.md, and ef263056... aligns docs/doctoring.md with the 3 September 2026 W3C Working Draft (https://www.w3.org/TR/2026/WD-webdriver-bidi-20260903/) and the reusable-versus-exclusive cleanup boundary. Exact file reads now satisfy the repository contract’s dated-URI/timezone/media/cleanup requirements.

This does not advance browser-runtime acceptance. Current exact CI 34219091919 completed skipped while Draft, so there is no exact-head hosted Rust/Python/Clippy/rustdoc/100%-coverage GREEN. The next buyer-visible RED remains real pinned Chromium: seed an unrelated pre-existing media override in the exact reusable target, apply OriginWeave reduced-motion, observe the intended presentation, run generic cleanup, and prove the unrelated state survives/restores. The alternative path must establish an actually exclusive disposable context/profile and prove destruction/cleanup at the Browser Session boundary. ExclusivePresentationContext alone is caller attestation, not ownership evidence; command ACK remains non-passing.

[seonghobae]

PR-state-only lease ACTIVE — no source/docs/ref mutation. Scope is only to replace the stale Dependency / delivery boundary in the issue body with current #293 exact ef2630566fdfd3c044075316a971cdade82e740f, repaired documentation state, skipped exact CI 34219091919, and the unchanged real pinned-Chromium acceptance. Preserve all browser-domain invariants, standards references, #229 prerequisite, #212 ownership boundary, open state, and no merge/release claim.