test(viewer): tokens SSOT proptest surface (WBS-6.2 #450) - #456
test(viewer): tokens SSOT proptest surface (WBS-6.2 #450)#456KooshaPari wants to merge 1 commit into
Conversation
Adds crates/sl-viewer/tests/properties_viewer_tokens.rs with 10
proptest properties pinning the design-token SSOT invariants:
* lab_coat::*:
* Every hex is a well-formed #RRGGBB (7-char lowercase ASCII hex).
* Every hex is non-empty.
* All 16 documented hex constants are pairwise distinct.
* Every hex appears in TOKENS_CSS so the Rust mirror and the
CSS SSOT stay in sync.
* REQUIRED_CSS_VARS:
* Every entry starts with --.
* Every entry is non-empty.
* The set is duplicate-free.
* Every entry appears in TOKENS_CSS.
* VIEWER_COLOR_SCHEME:
* Declares both :root and :root[data-theme dark] selectors.
* Uses color-scheme exactly twice.
Updates WBS-6.2 evidence list, TRACEABILITY.json, and CHANGELOG.
🤖 CodeAnt AI — Review Status
|
Thanks for using CodeAnt! 🎉We're free for open-source projects. if you're enjoying it, help us grow by sharing. Share on X · |
|
Warning Review limit reached
Next review available in: 41 minutes You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro Plus Run ID: 📒 Files selected for processing (4)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
codeant-ai
Bot
added
the
size:L
![codeant-ai[bot]](https://avatars.githubusercontent.com/in/646884?s=60&v=4){kind=small}
| let hex = lab_coat_hex_list()[i]; | ||
| prop_assert!( | ||
| TOKENS_CSS.contains(hex), | ||
| "TOKENS_CSS missing lab_coat hex {:?}", | ||
| hex, |
There was a problem hiding this comment.
Suggestion: This only checks that each hex string occurs somewhere in the entire stylesheet, not that it is assigned to the corresponding token. A token declaration can be changed or removed while the same color remains in another declaration, a comment, or an unrelated selector, and this property will still pass. Validate the expected variable-to-hex assignment on the same declaration line, as the existing unit test does. [api mismatch]
Severity Level: Major ⚠️
- ❌ Rust palette and CSS token assignments can silently diverge.
- ⚠️ Viewer colors can change for affected theme controls.
- ⚠️ `ThemeColors` users can receive mismatched CSS/Rust colors.
Prompt for AI Agent 🤖
This is a comment left during a code review.
**Path:** crates/sl-viewer/tests/properties_viewer_tokens.rs
**Line:** 114:118
**Comment:**
*Api Mismatch: This only checks that each hex string occurs somewhere in the entire stylesheet, not that it is assigned to the corresponding token. A token declaration can be changed or removed while the same color remains in another declaration, a comment, or an unrelated selector, and this property will still pass. Validate the expected variable-to-hex assignment on the same declaration line, as the existing unit test does.
Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.
Once fix is implemented, also check other comments on the same PR, and ask user if the user wants to fix the rest of the comments as well. if said yes, then fetch all the comments validate the correctness and implement a minimal fix| let var = REQUIRED_CSS_VARS[i]; | ||
| prop_assert!( | ||
| TOKENS_CSS.contains(var), | ||
| "TOKENS_CSS missing required CSS var {:?}", | ||
| var, |
There was a problem hiding this comment.
Suggestion: This accepts a required variable when its name appears only in a comment, a var(...) reference, or another non-declaration context. Consequently, removal of the actual custom-property definition can go undetected even though REQUIRED_CSS_VARS documents variables that must exist. Check for a CSS declaration of the form var: rather than an arbitrary substring. [api mismatch]
Severity Level: Major ⚠️
- ❌ Missing viewer variables can invalidate theme styles.
- ⚠️ CSS fallbacks may alter backgrounds, text, or accents.
- ⚠️ Required-token regression can pass CI unnoticed.
Prompt for AI Agent 🤖
This is a comment left during a code review.
**Path:** crates/sl-viewer/tests/properties_viewer_tokens.rs
**Line:** 155:159
**Comment:**
*Api Mismatch: This accepts a required variable when its name appears only in a comment, a `var(...)` reference, or another non-declaration context. Consequently, removal of the actual custom-property definition can go undetected even though `REQUIRED_CSS_VARS` documents variables that must exist. Check for a CSS declaration of the form `var:` rather than an arbitrary substring.
Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.
Once fix is implemented, also check other comments on the same PR, and ask user if the user wants to fix the rest of the comments as well. if said yes, then fetch all the comments validate the correctness and implement a minimal fix| prop_assert!(VIEWER_COLOR_SCHEME.contains(":root")); | ||
| prop_assert!(VIEWER_COLOR_SCHEME.contains("[data-theme=\"dark\"]")); |
There was a problem hiding this comment.
Suggestion: The two independent substring checks do not require the dark selector to be the exact :root[data-theme="dark"] selector. The fragments could occur in separate or malformed selectors and the property would still pass, allowing the selector consumed by the viewer to be missing. Assert the complete selector string or parse the selector block. [incorrect condition logic]
Severity Level: Major ⚠️
- ❌ Dark-mode selector regressions can escape the token test.
- ⚠️ Viewer dark-theme switching may stop applying color-scheme.
- ⚠️ Browser controls may retain the wrong light/dark styling.
Prompt for AI Agent 🤖
This is a comment left during a code review.
**Path:** crates/sl-viewer/tests/properties_viewer_tokens.rs
**Line:** 172:173
**Comment:**
*Incorrect Condition Logic: The two independent substring checks do not require the dark selector to be the exact `:root[data-theme="dark"]` selector. The fragments could occur in separate or malformed selectors and the property would still pass, allowing the selector consumed by the viewer to be missing. Assert the complete selector string or parse the selector block.
Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.
Once fix is implemented, also check other comments on the same PR, and ask user if the user wants to fix the rest of the comments as well. if said yes, then fetch all the comments validate the correctness and implement a minimal fix| prop_assert!(VIEWER_COLOR_SCHEME.contains("color-scheme")); | ||
| // Both modes must set the property. | ||
| let occurrences = VIEWER_COLOR_SCHEME.matches("color-scheme").count(); | ||
| prop_assert_eq!(occurrences, 2); |
There was a problem hiding this comment.
Suggestion: Counting textual occurrences does not prove that light and dark selectors each contain one color-scheme declaration. Occurrences in comments, duplicate declarations within one rule, or two declarations using the same value all satisfy this assertion while one theme mode remains incorrect. Validate the declarations associated with each selector and their expected values. [incorrect condition logic]
Severity Level: Major ⚠️
- ❌ Browser controls can use the wrong theme color scheme.
- ⚠️ Dark-mode scrollbar and form-control styling may regress.
- ⚠️ Viewer theme switching can pass CI with incomplete CSS.
Prompt for AI Agent 🤖
This is a comment left during a code review.
**Path:** crates/sl-viewer/tests/properties_viewer_tokens.rs
**Line:** 181:184
**Comment:**
*Incorrect Condition Logic: Counting textual occurrences does not prove that light and dark selectors each contain one `color-scheme` declaration. Occurrences in comments, duplicate declarations within one rule, or two declarations using the same value all satisfy this assertion while one theme mode remains incorrect. Validate the declarations associated with each selector and their expected values.
Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.
Once fix is implemented, also check other comments on the same PR, and ask user if the user wants to fix the rest of the comments as well. if said yes, then fetch all the comments validate the correctness and implement a minimal fix
|
Closing due to merge conflicts. |
![kilo-code-bot[bot]](https://avatars.githubusercontent.com/in/2193792?s=60&v=4){kind=small}
| /// starting with `#`. Since we can't introspect Rust modules at runtime, | ||
| /// we hard-code the list (mirroring `tokens.rs`). The constants are | ||
| /// public — any new addition requires also extending this list, which | ||
| /// the `proptest` exhaustiveness check below will catch. |
There was a problem hiding this comment.
WARNING: The lab_coat_hex_list() doc promises an 'exhaustiveness check' that does not exist.
The doc comment (lines 45–50) claims the list is derived via a 'reflection-on-source approach' over every pub const in lab_coat, and that any new constant addition 'will [be] catch[ed] by the proptest exhaustiveness check below.' Neither is true: the list is hand-maintained (no reflection), and none of the 10 properties cross-checks lab_coat_hex_list() against the full set of lab_coat constants. A new lab_coat::* constant added without extending this list would silently escape coverage — precisely the drift this SSOT test surface is meant to prevent.
Suggested fix: either (a) add a property asserting lab_coat_hex_list().len() equals the documented count (16) and that every lab_coat::* value is present, or (b) reword the doc to state the list must be updated manually and the suite does not assert completeness.
Reply with @kilocode-bot fix it to have Kilo Code address this issue.
Code Review SummaryStatus: 1 Issue Found | Recommendation: Address before merge
Overview
Issue Details (click to expand)WARNING
Consider / Notes (click to expand)
Files Reviewed (4 files)
Fix these issues in Kilo Cloud Reviewed by laguna-s-2.1:free · Input: 195.1K · Output: 26.2K · Cached: 259.6K |
* test(viewer): help_overlay shortcut proptest surface (WBS-6.2 #455) Adds crates/sl-viewer/tests/properties_viewer_help_overlay.rs with 13 proptest properties pinning the keyboard help SSOT: * SHORTCUTS is non-empty. * Every shortcut has non-empty keys / scope / action. * Every action is descriptive (has at least one ASCII letter) and human-readable (no ERR_ / error code leaks). * Every (keys, scope) pair is unique so the rendered table does not collide on its React key. * The ?, Escape, and Cmd+K / Ctrl+K shortcuts are present. * Every scope is one of the documented panel scopes. * Every keys is non-blank. Updates WBS-6.2 evidence list, TRACEABILITY.json, and CHANGELOG. * test(viewer): settings_tab HealthStatus proptest surface (WBS-6.2 #456) Adds crates/sl-viewer/tests/properties_viewer_settings_tab.rs with 11 proptest properties pinning the settings tab SSOT: * HealthStatus::Unknown.label() is , Healthy is , Unreachable is . * Every label is non-empty, distinct across variants, single-line, and lowercase ASCII. * label() is deterministic across calls. * THEME_RADIO_GROUP_ID is non-empty, kebab-case ASCII, and distinct from FORGE_DB_HINT_STORAGE_KEY. Updates WBS-6.2 evidence list, TRACEABILITY.json, and CHANGELOG. * test(viewer): menu id taxonomy proptest surface (WBS-6.2 #457) Adds crates/sl-viewer/tests/properties_viewer_menu.rs with 5 proptest properties pinning the desktop menu id SSOT: * Every documented menu id (9 of them: ID_APP_ABOUT, ID_APP_SETTINGS, ID_FILE_RELOAD_DISCOVERY, ID_FILE_SETTINGS, ID_EDIT_FIND, ID_VIEW_RELOAD, ID_VIEW_TOGGLE_THEME, ID_VIEW_COMMAND_PALETTE, ID_HELP_TOGGLE) is non-empty. * Every id is kebab-case ASCII so muda / JS / serde round-trips are safe. * Every id carries the documented sl-viewer. prefix. * Every id is unique across the documented set. * The menu taxonomy has exactly 9 documented ids. Updates WBS-6.2 evidence list, TRACEABILITY.json, and CHANGELOG. --------- Co-authored-by: SessionLedger Bot <team@sessionledger.local>
User description
Summary
Adds
crates/sl-viewer/tests/properties_viewer_tokens.rswith 10 proptest properties pinning thetokensmodule SSOT invariants (WBS-6.2 #450).lab_coat::*(4 properties)#RRGGBB(7-char lowercase ASCII hex).TOKENS_CSS.REQUIRED_CSS_VARS(4 properties)--.TOKENS_CSS.VIEWER_COLOR_SCHEME(2 properties):rootand:root[data-theme="dark"]selectors.color-schemeexactly twice.Validation
cargo test -p sl-viewer --test properties_viewer_tokens --features "desktop parquet" --locked— 10 passedcargo fmt --all --check— cleanWBS / TRACEABILITY
WBS-6.2 evidence list and
TRACEABILITY.jsongaincrates/sl-viewer/tests/properties_viewer_tokens.rs. CHANGELOG Unreleased documents the new surface.CodeAnt-AI Description
Add property coverage for viewer color-token consistency
What Changed
Impact
✅ Fewer theme token mismatches✅ Safer light and dark theme updates✅ Earlier detection of invalid viewer colors💡 Usage Guide
Checking Your Pull Request
Every time you make a pull request, our system automatically looks through it. We check for security issues, mistakes in how you're setting up your infrastructure, and common code problems. We do this to make sure your changes are solid and won't cause any trouble later.
Talking to CodeAnt AI
Got a question or need a hand with something in your pull request? You can easily get in touch with CodeAnt AI right here. Just type the following in a comment on your pull request, and replace "Your question here" with whatever you want to ask:
This lets you have a chat with CodeAnt AI about your pull request, making it easier to understand and improve your code.
Example
Preserve Org Learnings with CodeAnt
You can record team preferences so CodeAnt AI applies them in future reviews. Reply directly to the specific CodeAnt AI suggestion (in the same thread) and replace "Your feedback here" with your input:
This helps CodeAnt AI learn and adapt to your team's coding style and standards.
Example
Retrigger review
Ask CodeAnt AI to review the PR again, by typing:
Check Your Repository Health
To analyze the health of your code repository, visit our dashboard at https://app.codeant.ai. This tool helps you identify potential issues and areas for improvement in your codebase, ensuring your repository maintains high standards of code health.