refactor(browser): split css/values/apply.rs into apply/ submodule

[AndrewAltimit]

Summary

crates/oasis-browser/src/css/values/apply.rs had grown to 4412 lines bundling four unrelated concerns. Split along those concern boundaries into a sibling-file submodule.

File	Lines	Concern
apply/mod.rs	2074	`apply_declaration` per-property dispatch match
apply/parsers.rs	918	Free value-token parsers (`transform`, `clip-path`, `filter`, `grid-template-areas`, font families, ...)
apply/tests.rs	960	The test module
apply/initial.rs	418	`apply_initial` reset, transition/animation shorthands, inline-logical resolution
apply/container.rs	118	`will-change` + `container` shorthand parsing

No file in the split exceeds 2500 lines. Pure mechanical move; no behaviour change.

Test plan

• `cargo build --workspace`
• `cargo fmt --all -- --check`
• `cargo clippy --workspace -- -D warnings`
• `cargo test -p oasis-browser` — 1954 passing
• `cargo test -p oasis-browser --test visual_regression` — both 800x600 and 480x272 corpus goldens unchanged

[github-actions]

Openrouter AI General Review

Issues (if any)

(none)

Previous Issues (for incremental reviews)

(none)

Suggestions (if any)

• crates/oasis-browser/src/css/values/apply/mod.rs:11 - Verify as_keyword and resolve_length are still consumed within mod.rs's apply_declaration match arms. If all their call sites were moved to parsers.rs or initial.rs, remove these imports to satisfy -D warnings.

Notes

• 1 claim(s) were automatically filtered as potential hallucinations (file:line content didn't match claims)

• The refactoring cleanly partitions the monolithic apply.rs [UNVERIFIED - File does not exist and is not in PR] into logical submodules without altering control flow or data structures.

• pub(super) visibility is correctly applied to cross-file helpers, maintaining encapsulation while allowing sibling access within the apply module.

• Test paths (super::parsers::parse_time) and #[cfg(test)] module placement are correctly updated.

• No copy-paste errors, missing imports, or behavioral regressions detected in the diff.

---

Generated by Openrouter AI (qwen/qwen3.6-plus). Supplementary to human reviews.

[github-actions]

Claude AI Architecture & Quality Review

The grep confirms the three pub(crate) → pub(super) downgrades are safe — will_change_promotes, parse_container_name_list, and parse_container_shorthand are only called from within apply/mod.rs, never from elsewhere in the crate.

Issues (if any)

(none)

Previous Issues (for incremental reviews)

(none)

Suggestions (if any)

• crates/oasis-browser/src/css/values/apply/parsers.rs:74 — parse_origin_length is only called from within parsers.rs itself (parse_transform_origin), so pub(super) is wider than needed. Could be private fn.

• crates/oasis-browser/src/css/values/apply/initial.rs:153 — parse_animation duplicates the parse_iteration_count guard inline (tok == "infinite" / tok.parse::<f32>()) instead of calling parsers::parse_iteration_count. Minor inconsistency, was pre-existing in the monolith, but the split is a natural opportunity to unify.

Notes

• The pub(crate) → pub(super) downgrade on will_change_promotes, parse_container_name_list, and parse_container_shorthand is correct: grep confirms all three are only called from apply/mod.rs. The original pub(crate) was overly broad.
• ComputedStyle methods (parse_transition, parse_animation, etc.) correctly widened from private to pub(super) — necessary for initial.rs to call them while still blocking access from outside the apply submodule.
• Test imports (use super::parsers::parse_time) are structurally sound; tests is a sibling of parsers within the apply/ module tree.
• Split boundaries are well-chosen: dispatch match in mod.rs, free-function parsers in parsers.rs, ComputedStyle mutation helpers in initial.rs, shorthand-specific container logic in container.rs. No concern with the partition.

---

Generated by Claude AI (sonnet). Supplementary to human reviews.

[github-actions]

Claude AI Incremental Security & Correctness Review

This is an incremental review focusing on changes since the last review.

Issues (if any)

(none)

Previous Issues (for incremental reviews)

• [RESOLVED] Previous reviewers noted no issues; this review confirms the same.

Suggestions (if any)

• crates/oasis-browser/src/css/values/apply/parsers.rs:74 — parse_origin_length is pub(super) but is only called from within parsers.rs itself (by parse_transform_origin). Could be fn (private). Carried over from previous Claude review — still applicable.

Notes

• This is a pure mechanical split: no logic moved between call sites, no behavior changed. All parsers, dispatch arms, and test assertions are identical to the pre-split monolith.
• resolve_content_counters remains a dead-code placeholder (#[allow(dead_code)]) that silently returns content unchanged — pre-existing gap, not introduced here.
• pub(super) downgrades on will_change_promotes, parse_container_name_list, and parse_container_shorthand are correct: all three are only consumed by apply/mod.rs.
• ComputedStyle methods in initial.rs correctly widened from private to pub(super) — necessary for cross-file access within the submodule without leaking to the rest of the crate.
• Test file correctly uses #![allow(clippy::unwrap_used)] scoped to the test module only.

---

Generated by Claude AI (sonnet). Supplementary to human reviews.

[AndrewAltimit]

Review Response Agent (Iteration 1)

Status: Changes committed, pushing...

Commit: 6003b99

Fixed Issues

• crates/oasis-browser/src/css/values/apply/parsers.rs:459 — Narrowed parse_origin_length from pub(super) to private fn. Grep confirmed it's only called once, from parse_transform_origin in the same file. Verified with cargo clippy -p oasis-browser -- -D warnings.

Ignored Issues

• OpenRouter's claim that as_keyword and resolve_length imports in apply/mod.rs:11 may be unused — false. Both are used heavily throughout the dispatch match (130+ call sites for as_keyword, 30+ for resolve_length). Verified by grep. The reviewer also flagged this as "1 claim auto-filtered as potential hallucination" so the system already partially caught it.
• Claude Quality's note about parse_animation duplicating the parse_iteration_count guard inline in initial.rs:153 — pre-existing in the monolith, explicitly out of scope for a mechanical split refactor PR. Reviewer themselves acknowledged it was pre-existing.

Deferred to Human

• (none)

Notes

• All three reviewers (OpenRouter, Claude Quality, Claude Security) reported zero blocking issues for this mechanical split. Only minor suggestions.
• The PR is a pure file-organization refactor; behavior is unchanged and the test suite (1954 tests) passes.

---

Automated summary of agent fixes.

[github-actions]

Openrouter AI Incremental General Review

This is an incremental review focusing on changes since the last review.

Issues (if any)

• [BUG] crates/oasis-browser/src/css/values/apply/mod.rs:22 - Incorrect relative paths for resolve and types imports.
  • mod.rs resides in apply/, so super correctly points to values/. Using super::super::resolve and super::super::types incorrectly points to css/, which will cause compilation errors.
  • Fix: Change super::super::resolve to super::resolve and super::super::types to super::types.

Previous Issues (for incremental reviews)

• [RESOLVED] crates/oasis-browser/src/css/values/apply/parsers.rs:74 - parse_origin_length narrowed to private fn.

Suggestions (if any)

(none)

Notes

• The split cleanly partitions concerns without altering logic.
• All submodule files (parsers.rs, initial.rs, container.rs) correctly use super::super:: to reach values/, but mod.rs incorrectly adopted the same depth during the refactor.
• Visibility changes (pub(crate) -> pub(super)) are correctly applied and scoped.
• Test imports and #[cfg(test)] module placement are structurally sound.

---

Generated by Openrouter AI (qwen/qwen3.6-plus). Supplementary to human reviews.

[github-actions]

Claude AI Incremental Security & Correctness Review

This is an incremental review focusing on changes since the last review.

Issues (if any)

(none)

Previous Issues (for incremental reviews)

• [STILL UNRESOLVED — FALSE POSITIVE] crates/oasis-browser/src/css/values/apply/mod.rs:22 - The OpenRouter reviewer's claim that super::resolve and super::types are wrong is incorrect.
  • mod.rs lives at css/values/apply/mod.rs. Its super resolves to css/values/, which is exactly where resolve and types live. The paths are correct.
  • The reviewer incorrectly assumed mod.rs has the same depth as the sibling files (parsers.rs, initial.rs, container.rs), which use super::super:: because they need to go through apply/ → values/. But mod.rs is the apply module — its super is values/ directly.
  • This is verified by reading mod.rs lines 14–31 in the actual file.

Suggestions (if any)

(none)

Notes

• The new parsers.rs file is a clean extraction with no correctness regressions. All free-function parsers are identical to their originals; only visibility and file location changed.
• parse_origin_length correctly remains private fn (the fix from iteration 1 is present and correct).
• No security-relevant code paths changed; all input parsing is identical to the pre-split monolith.

---

Generated by Claude AI (sonnet). Supplementary to human reviews.

[github-actions]

Claude AI Incremental Architecture & Quality Review

This is an incremental review focusing on changes since the last review.

Issues (if any)

(none)

Previous Issues (for incremental reviews)

• [STILL UNRESOLVED — FALSE POSITIVE] crates/oasis-browser/src/css/values/apply/mod.rs:22 — OpenRouter's claim that super::resolve / super::types paths are wrong.
  • mod.rs is the apply module at css/values/apply/mod.rs; its super resolves to css/values/, which is exactly where resolve and types live. Sibling files (parsers.rs, initial.rs, container.rs) need super::super:: to traverse up through apply/ into values/, but mod.rs does not.
  • Confirmed correct by reading the diff. No fix needed.

Suggestions (if any)

• crates/oasis-browser/src/css/values/apply/parsers.rs:860,875,889 — keyword_to_family_name, collect_font_family_names, and flush_pending_idents are all pub(super) but are only called within parsers.rs itself (all three are internal helpers for parse_font_family_value). Same pattern as parse_origin_length fixed in iteration 1 — could be private fn. Clippy doesn't flag these because they are technically reachable via pub(super), but the visibility is wider than necessary.

Notes

• The super::resolve / super::types path claims from OpenRouter remain a false positive across both review iterations. The module hierarchy is unambiguous: mod.rs at apply/mod.rs has values/ as its super.
• This is a pure mechanical split; no behavioral change, no logic moved between call sites. The 1954-test green baseline from the PR description covers the split adequately.
• parse_iteration_count is imported in mod.rs from parsers — it is used somewhere in the 2074-line dispatch body (confirmed implicitly by the passing -D warnings clippy run).

---

Generated by Claude AI (sonnet). Supplementary to human reviews.

[AndrewAltimit]

Review Response Agent (Iteration 2)

Status: Changes committed, pushing...

Commit: 25191a2

Fixed Issues

• crates/oasis-browser/src/css/values/apply/parsers.rs:862,876,911 — Narrowed keyword_to_family_name, collect_font_family_names, and flush_pending_idents from pub(super) to private fn. Grep confirmed all three are only called within parsers.rs (callers: parse_font_family_value and each other). cargo clippy -p oasis-browser -- -D warnings passes clean. Same pattern as the iteration-1 fix on parse_origin_length.

Ignored Issues

• OpenRouter's claim that apply/mod.rs:14,19 should use super::resolve / super::types instead of the existing super::super::* paths — false positive. Reading the file confirms mod.rs already uses super::resolve and super::types (lines 14 and 19), not super::super::. Both Claude reviewers (security and quality) explicitly identified the OpenRouter claim as a false positive in their incremental reviews; clippy continues to pass -D warnings.

Deferred to Human

• (none)

Notes

• Both Claude reviewers reported zero blocking issues on commit 6003b99. Only Claude Quality flagged the visibility-narrowing suggestion, which mirrors the pattern fixed in iteration 1.
• Behavior is unchanged; this is purely a visibility tightening on three private helpers.

---

Automated summary of agent fixes.

[github-actions]

Claude AI Incremental Security & Correctness Review

This is an incremental review focusing on changes since the last review.

Issues (if any)

• [BUG] crates/oasis-browser/src/css/values/apply/parsers.rs:319 - rem suffix check unreachable in parse_transform_length

  • strip_suffix("em") matches before strip_suffix("rem"): for input "1.5rem", strip_suffix("em") yields Some("1.5r"), which fails .parse::<f32>() and silently returns 0.0 * parent_font_size = 0.0. The rem branch is never reached for valid rem inputs.
  • Fix: check rem before em — swap the two else if branches.

• [BUG] crates/oasis-browser/src/css/values/apply/parsers.rs:459 - Same em/rem suffix order bug in parse_origin_length

  • Identical pattern: strip_suffix("em") fires on rem values before the rem branch, resolving to 0.0 instead of v * current_root_font_size().
  • Fix: same — check rem first.

Previous Issues (for incremental reviews)

• [RESOLVED — FALSE POSITIVE] crates/oasis-browser/src/css/values/apply/mod.rs:22 — super::resolve / super::types path claims from OpenRouter. Both Claude security reviews (iterations 1 and 2) confirmed the paths are correct: mod.rs at apply/mod.rs has values/ as its super, so super::resolve and super::types are accurate. No fix needed.

Suggestions (if any)

(none)

Notes

• 1 claim(s) were automatically filtered as potential hallucinations (file:line content didn't match claims)

• Both bugs are pre-existing in the monolith (apply.rs [UNVERIFIED - File does not exist and is not in PR]) and carried over mechanically. The split is the natural opportunity to fix them since the affected functions are now isolated in parsers.rs.

• resolve_content_counters remains a dead-code placeholder (#[allow(dead_code)]) that returns content unchanged — pre-existing, out of scope here.

• No security-relevant issues; all parsing is pure value conversion with no external side effects.

---

Generated by Claude AI (sonnet). Supplementary to human reviews.

[github-actions]

Claude AI Incremental Architecture & Quality Review

This is an incremental review focusing on changes since the last review.

Issues (if any)

(none) — the only changes in commit 25191a2 are three visibility narrowings (pub(super) → private fn on keyword_to_family_name, collect_font_family_names, flush_pending_idents). These are correct and safe.

Previous Issues (for incremental reviews)

• [RESOLVED — FALSE POSITIVE] crates/oasis-browser/src/css/values/apply/mod.rs:22 — OpenRouter's claim that super::resolve/super::types paths are wrong. mod.rs at apply/mod.rs has values/ as its super; the paths are correct. No fix needed.

• [STILL UNRESOLVED] crates/oasis-browser/src/css/values/apply/parsers.rs:319 — rem suffix check unreachable in nested parse_transform_length.

  • strip_suffix("em") fires on "1.5rem" before the rem branch: yields Some("1.5r"), which fails parse::<f32>(), returns 0.0 * parent_font_size = 0.0. The rem branch is dead.
  • Fix: swap the two else if arms — check rem before em.

• [STILL UNRESOLVED] crates/oasis-browser/src/css/values/apply/parsers.rs:459 — Same em/rem suffix order bug in parse_origin_length.

  • Identical pattern: strip_suffix("em") fires on rem inputs, resolves to 0.0 instead of v * current_root_font_size().
  • Fix: check rem first.

Suggestions (if any)

(none)

Notes

• Commit 25191a2 is a pure visibility-tightening patch: the three font-family helper functions (keyword_to_family_name, collect_font_family_names, flush_pending_idents) are only called within parsers.rs itself, so narrowing to private fn is correct and mirrors the iteration-1 fix on parse_origin_length.
• The two em/rem ordering bugs were pre-existing in the monolith and carried over mechanically during the split. Both were first flagged by the security reviewer on commit 25191a2 and remain unfixed. They silently return 0.0 for any rem value in transform functions and transform-origin Z — a behavioral regression on any page using rem units for 3D transforms.

---

Generated by Claude AI (sonnet). Supplementary to human reviews.

[github-actions]

Openrouter AI Incremental General Review

This is an incremental review focusing on changes since the last review.

Issues (if any)

• [BUG] crates/oasis-browser/src/css/values/apply/parsers.rs:319 - rem suffix check unreachable in parse_transform_length

  • strip_suffix("em") matches before strip_suffix("rem"): for input "1.5rem", it yields Some("1.5r"), which fails .parse::<f32>() and silently returns 0.0 * parent_font_size = 0.0. The rem branch is never reached for valid rem inputs.
  • Fix: swap the two else if branches — check rem before em.

• [BUG] crates/oasis-browser/src/css/values/apply/parsers.rs:459 - Same em/rem suffix order bug in parse_origin_length

  • Identical pattern: strip_suffix("em") fires on rem values before the rem branch, resolving to 0.0 instead of v * current_root_font_size().
  • Fix: same — check rem first.

Previous Issues (for incremental reviews)

• [RESOLVED] crates/oasis-browser/src/css/values/apply/mod.rs:22 - Incorrect relative paths for resolve and types imports.
  • mod.rs at css/values/apply/mod.rs correctly uses super::resolve and super::types, which resolve to css/values/resolve and css/values/types. The previous claim was a false positive.

Suggestions (if any)

(none)

Notes

• Both bugs are pre-existing in the monolith and carried over mechanically during the split. They silently return 0.0 for any rem value in transform functions and transform-origin Z — a behavioral regression on any page using rem units for 3D transforms.
• The split boundaries are well-chosen and the mechanical move is clean. No copy-paste errors, missing imports, or behavioral regressions detected beyond the two pre-existing suffix-order bugs.
• pub(super) visibility is correctly applied to cross-file helpers, maintaining encapsulation while allowing sibling access within the apply module.

---

Generated by Openrouter AI (qwen/qwen3.6-plus). Supplementary to human reviews.

[AndrewAltimit]

Review Response Agent (Iteration 3)

Status: Changes committed, pushing...

Commit: e20ec3e

Fixed Issues

• crates/oasis-browser/src/css/values/apply/parsers.rs:326 (parse_transform_length) — Swapped the em/rem branch order. strip_suffix("em") was matching "1.5rem" first (yielding "1.5r", which fails parse::<f32>() and silently returns 0.0 * parent_font_size), making the rem branch unreachable. Now checks rem before em. Confirmed by reading lines 326–338.
• crates/oasis-browser/src/css/values/apply/parsers.rs:459 (parse_origin_length) — Same suffix-shadowing bug; identical fix. Both Claude Security and OpenRouter flagged this on iteration 2.
• crates/oasis-browser/src/css/values/apply/parsers.rs:605 (parse_clip_path::parse_len closure) — Identical pattern not flagged by reviewers but obviously buggy (third occurrence the reviewers missed). Same fix applied for consistency since all three occurrences were touched in the split.
• Added one short comment at the rem-branch in each of the three sites explaining why rem must precede em (suffix shadowing). Comment is the kind of non-obvious "WHY" justified by CLAUDE.md guidance — without it, a future maintainer would naturally re-order alphabetically and reintroduce the bug.

Ignored Issues

• OpenRouter's prior-iteration claim about apply/mod.rs:22 super::resolve / super::types paths — already addressed in iteration 2: confirmed false positive by both Claude reviewers; admin's iteration-2 summary documented this. No fix needed; not re-flagged this iteration.
• Claude Quality's iteration-1 note about parse_animation duplicating the parse_iteration_count guard inline (initial.rs:153) — explicitly out of scope per admin iteration-1 decision (pre-existing in monolith; mechanical-split PR scope).

Deferred to Human

• (none)

Notes

• Verified with cargo clippy -p oasis-browser -- -D warnings (clean) and cargo test -p oasis-browser --lib (1954 passed, 0 failed, 2 ignored).
• The reviewers correctly noted these bugs were pre-existing in the monolith. Unlike the iteration-1 stylistic note about parse_animation, these are real correctness bugs (rem values silently resolve to 0.0 in 3D transforms and transform-origin-Z), so worth fixing now while the affected functions are isolated.
• The third occurrence (line 605, parse_clip_path) was not in the reviewer reports but is the identical bug; fixing it now avoids a future reviewer flagging the leftover.

---

Automated summary of agent fixes.

[github-actions]

Openrouter AI Incremental General Review

This is an incremental review focusing on changes since the last review.

Issues (if any)

(none)

Previous Issues (for incremental reviews)

• [RESOLVED] crates/oasis-browser/src/css/values/apply/parsers.rs:319 - rem suffix check unreachable in parse_transform_length
• [RESOLVED] crates/oasis-browser/src/css/values/apply/parsers.rs:459 - Same em/rem suffix order bug in parse_origin_length
• [RESOLVED] crates/oasis-browser/src/css/values/apply/parsers.rs:605 - Identical em/rem suffix order bug in parse_clip_path::parse_len closure

Suggestions (if any)

(none)

Notes

• 1 claim(s) were automatically filtered as potential hallucinations (file:line content didn't match claims)

• The mechanical split cleanly partitions the monolithic apply.rs [UNVERIFIED - File does not exist and is not in PR] into logical submodules (mod.rs, parsers.rs, initial.rs, container.rs, tests.rs) without altering control flow or data structures.

• The rem/em suffix shadowing bug has been correctly fixed in all three occurrences (parse_transform_length, parse_origin_length, and parse_clip_path::parse_len), with clear inline comments explaining the non-obvious ordering requirement to prevent future regressions.

• Visibility narrowing (pub(crate) → pub(super) → private fn) is correctly applied across the new files, maintaining strict encapsulation while allowing necessary sibling access.

• Test imports (super::parsers::parse_time) and #[cfg(test)] module placement are structurally sound and compile correctly within the new hierarchy.

• No copy-paste errors, missing imports, or behavioral regressions detected in the diff.

---

Generated by Openrouter AI (qwen/qwen3.6-plus). Supplementary to human reviews.

[github-actions]

Claude AI Incremental Security & Correctness Review

This is an incremental review focusing on changes since the last review.

Issues (if any)

(none)

Previous Issues (for incremental reviews)

• [RESOLVED] crates/oasis-browser/src/css/values/apply/parsers.rs:319 — rem suffix check unreachable in parse_transform_length. Now checks rem before em at line 330 with explanatory comment.
• [RESOLVED] crates/oasis-browser/src/css/values/apply/parsers.rs:459 — Same em/rem suffix order bug in parse_origin_length. Fixed at line 465 with explanatory comment.
• [RESOLVED] crates/oasis-browser/src/css/values/apply/parsers.rs (clip-path parse_len closure) — Third occurrence of the same suffix-ordering bug, fixed at line 614 with explanatory comment.

Suggestions (if any)

(none)

Notes

• All three em/rem suffix-shadowing bugs are confirmed fixed in parsers.rs with inline comments explaining the ordering requirement. The fixes are mechanically correct and the comments prevent regression.
• The parse_time suffix ordering ("ms" before 's') is also correct — "ms" is checked first so "100ms" cannot accidentally match the bare 's' strip and produce a malformed parse.
• No new security or correctness issues introduced in parsers.rs. All code is pure value-to-enum conversion with no I/O, external calls, or unsafe blocks.

---

Generated by Claude AI (sonnet). Supplementary to human reviews.

[github-actions]

Claude AI Incremental Architecture & Quality Review

This is an incremental review focusing on changes since the last review.

Issues (if any)

(none)

Previous Issues (for incremental reviews)

• [RESOLVED] crates/oasis-browser/src/css/values/apply/mod.rs:22 — Import path false positive. mod.rs at apply/mod.rs has values/ as its super; super::resolve and super::types are correct. Confirmed across all three prior Claude iterations.

• [RESOLVED] crates/oasis-browser/src/css/values/apply/parsers.rs:319 — rem suffix check unreachable in parse_transform_length. Fixed: rem is now checked before em with an explanatory comment at line ~330.

• [RESOLVED] crates/oasis-browser/src/css/values/apply/parsers.rs:459 — Same em/rem suffix order bug in parse_origin_length. Fixed: rem now precedes em with explanatory comment. Also fixed in the parse_clip_path::parse_len closure (third occurrence from iteration 3).

Suggestions (if any)

(none)

Notes

• All three em/rem suffix-shadowing bugs are confirmed fixed across parse_transform_length, parse_origin_length, and the parse_clip_path::parse_len closure. Each fix includes an inline comment explaining the ordering invariant.
• The pub(super) visibility on initial.rs methods (parse_transition, parse_animation, etc.) is correct — mod.rs needs to call them via Self:: while they should not be visible outside the apply submodule.
• initial.rs correctly imports sibling parsers via super::parsers and mod.rs correctly reaches values/ via super::resolve/super::types. Module hierarchy is sound.
• resolve_content_counters dead-code placeholder remains — pre-existing, out of scope for this refactor PR.

---

Generated by Claude AI (sonnet). Supplementary to human reviews.

[AndrewAltimit]

Review Response Agent (Iteration 4)

Status: Hallucination detected — no commit

Detection: The agent's summary below claims to have applied fixes, > but Claude made zero file-mutating tool calls (Edit / Write / MultiEdit / NotebookEdit) > during the run. The retry was skipped because it uses the same prompting > strategy Claude already ignored.

Stream log: /home/mikunpc/Documents/repos/actions-runner-oasis-os/_work/_temp/review-agent-logs/claude-stream-iter3-1777803619123.jsonl
Uploaded as the review-agent-claude-logs workflow artifact.

Fixed Issues

• (none — no Edits made this iteration)

Ignored Issues

• All three em/rem suffix-shadowing bugs in crates/oasis-browser/src/css/values/apply/parsers.rs (parse_transform_length ~line 330, parse_origin_length ~line 465, parse_clip_path::parse_len ~line 614) — already fixed in prior iteration (commit e20ec3e). Verified by reading lines 326–339 of parsers.rs: rem is checked before em with explanatory comments at all three sites.
• OpenRouter false-positive on apply/mod.rs:22 (super::resolve / super::types paths) — already addressed/dismissed in iteration 2; both Claude reviewers (security and quality) reconfirmed it as a false positive on every subsequent commit, including HEAD.
• Claude Quality iteration-1 stylistic note about parse_animation duplicating the parse_iteration_count guard inline — already explicitly deferred as out-of-scope for the mechanical-split PR (pre-existing in the monolith); not re-flagged on subsequent reviews.

Deferred to Human

• (none)

Notes

• All three reviewer comments on the current HEAD commit e20ec3e report zero issues and zero suggestions. Every previously flagged item is marked [RESOLVED].
• No code changes are warranted. The branch is in a clean state for merge from a review-feedback standpoint.

---

No file modifications were performed; this iteration produced no commit.