Repository navigation
fix(driver): map absolute percents as range positions and keep tiny-step precision - #239
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
51241a5 to
9966c5f
Compare
828ff34 to
c4ecbe2
Compare
c4ecbe2 to
f97dacf
Compare
9966c5f to
5e9fc61
Compare
5e9fc61 to
d8af837
Compare
f97dacf to
6fccaa4
Compare
pbroom
left a comment
pbroom
left a comment
There was a problem hiding this comment.
Reviewed the full incremental PR and its corrections at 6fccaa4eeaac1264350f81d7ff05b4e66a681d39. Precision regression corrected and independently tested. No remaining actionable findings in the reviewed scope.
Independent correction re-reviews and stack preservation verification passed. At the integrated tip, lint, full build/DTS, 2,208 tests, formatting, strict agent checks and 14 built-site Chrome tests passed. All recorded actionable review threads are addressed. Hosted CI is being verified separately; this review does not authorize merge or release.
d8af837 to
c79d502
Compare
6fccaa4 to
3d503c0
Compare
…tep precision
parseColorInputExpression evaluated each absolute % as a span fraction
and added range[0] once to the whole result, so on an offset range any
expression that multiplied or combined percents was wrong ('50% * 2' on
[100, 200] gave 200). Every absolute % is now a position in the range,
like a lone '50%'; relative input keeps span fractions.
getColorInputPrecisionFromStep used an absolute rounding tolerance, so
steps below 1e-7 looked like whole numbers and returned 0. The tolerance
is now relative to the step, and such steps return the 6-decimal cap.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
3d503c0 to
1597d57
Compare
This branch was successfully deployed
1 participant
parseColorInputExpression evaluated each absolute % as a span fraction
and added range[0] once to the whole result, so on an offset range any
expression that multiplied or combined percents was wrong ('50% * 2' on
[100, 200] gave 200). Every absolute % is now a position in the range,
like a lone '50%'; relative input keeps span fractions.
getColorInputPrecisionFromStep used an absolute rounding tolerance, so
steps below 1e-7 looked like whole numbers and returned 0. The tolerance
is now relative to the step, and such steps return the 6-decimal cap.
Found while documenting the public API in #235. Each finding was reproduced against the built package before the fix, has a regression test, and its affected JSDoc examples were recomputed. lint, build, test, format:check, typecheck, size, check:artifacts, check:preprod and agents:check:strict pass.
Part of the color-kit assessment stack.
🤖 Generated with Claude Code