test(viewer): tokens SSOT proptest surface (WBS-6.2 #450) - #459
test(viewer): tokens SSOT proptest surface (WBS-6.2 #450)#459KooshaPari 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: 32 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 |
| fn lab_coat_hex_in_tokens_css(i in lab_coat_hex_indices_strategy()) { | ||
| 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 occurs somewhere in the CSS, so the test passes if the value is present in a comment, an unrelated declaration, or under the wrong variable. Verify that each expected CSS variable is assigned the corresponding hex on its declaration line, as the existing unit test does. [possible bug]
Severity Level: Major ⚠️
- ⚠️ Viewer CSS can assign incorrect Lab-Coat colors.
- ⚠️ Rust and CSS palette mappings can silently diverge.
- ⚠️ Theme rendering may show incorrect semantic colors.Prompt for AI Agent 🤖
This is a comment left during a code review.
**Path:** crates/sl-viewer/tests/properties_viewer_tokens.rs
**Line:** 113:118
**Comment:**
*Possible Bug: This only checks that each hex occurs somewhere in the CSS, so the test passes if the value is present in a comment, an unrelated declaration, or under the wrong variable. Verify that each expected CSS variable is assigned the corresponding hex on its 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| fn required_css_var_in_tokens_css(i in required_var_index_strategy()) { | ||
| 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: A raw substring search can succeed when a required name appears only in a comment or as a prefix of a different custom-property name, without declaring the required variable. Parse or match CSS custom-property declarations with an exact variable-name boundary. [api mismatch]
Severity Level: Major ⚠️
- ❌ Missing CSS variables can invalidate viewer styles.
- ⚠️ `var(--sl-bg)` consumers may fall back unexpectedly.
- ⚠️ Required-token regression tests can report false success.Prompt for AI Agent 🤖
This is a comment left during a code review.
**Path:** crates/sl-viewer/tests/properties_viewer_tokens.rs
**Line:** 154:159
**Comment:**
*Api Mismatch: A raw substring search can succeed when a required name appears only in a comment or as a prefix of a different custom-property name, without declaring the required variable. Parse or match CSS custom-property declarations with an exact variable-name boundary.
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| fn viewer_color_scheme_declares_both_selectors(_i in 0u8..4) { | ||
| 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 contains checks do not prove that the dark selector is the exact :root[data-theme="dark"] selector. A malformed stylesheet with separate :root and [data-theme="dark"] rules would pass while failing to apply the theme to the document root; assert the exact selector or validate the parsed rule structure. [incorrect condition logic]
Severity Level: Major ⚠️
- ⚠️ Dark-mode browser controls may keep light styling.
- ⚠️ Root theme switching can lose its color-scheme rule.
- ⚠️ The integration property can miss selector regressions.Prompt for AI Agent 🤖
This is a comment left during a code review.
**Path:** crates/sl-viewer/tests/properties_viewer_tokens.rs
**Line:** 171:174
**Comment:**
*Incorrect Condition Logic: The two independent `contains` checks do not prove that the dark selector is the exact `:root[data-theme="dark"]` selector. A malformed stylesheet with separate `:root` and `[data-theme="dark"]` rules would pass while failing to apply the theme to the document root; assert the exact selector or validate the parsed rule structure.
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 two occurrences of the text color-scheme does not verify that light and dark modes receive the correct values or that each occurrence is a declaration in the intended rule. This allows both modes to be set to the same scheme, or allows occurrences in comments or unrelated text, while the property still passes. Assert the exact :root { color-scheme: light; } and dark declarations. [incomplete implementation]
Severity Level: Major ⚠️
- ⚠️ Native controls may use the wrong theme appearance.
- ⚠️ Scrollbar styling can remain inconsistent with viewer mode.
- ⚠️ Text-count validation permits comments and wrong values.Prompt for AI Agent 🤖
This is a comment left during a code review.
**Path:** crates/sl-viewer/tests/properties_viewer_tokens.rs
**Line:** 181:185
**Comment:**
*Incomplete Implementation: Counting two occurrences of the text `color-scheme` does not verify that light and dark modes receive the correct values or that each occurrence is a declaration in the intended rule. This allows both modes to be set to the same scheme, or allows occurrences in comments or unrelated text, while the property still passes. Assert the exact `:root { color-scheme: light; }` and dark declarations.
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. |
…ace (WBS-6.2 #463) (#479) * test(viewer): async_states SkeletonLayout proptest surface (WBS-6.2 #458) Adds crates/sl-viewer/tests/properties_viewer_async_states.rs with 7 proptest properties pinning the async_states SSOT: * SkeletonLayout::default() is Bundles. * SkeletonLayout exposes exactly three variants (Bundles, ListDetail, StreamFeed). * Every variant's Debug label is non-empty, single-line, and matches one of the documented names. * SkeletonLayout::default() matches the first arm in the match block in ContentSkeleton. * list_rows.clamp(3, 6) lands in [3, 6] for every input. * The clamp is monotonic non-decreasing. * The clamp has the documented fixed points (0/2 -> 3, 6/MAX -> 6). Updates WBS-6.2 evidence list, TRACEABILITY.json, and CHANGELOG. * test(viewer): session-ledger OKF document validator proptest surface (WBS-6.2 #459) Adds crates/sl-viewer/tests/properties_session_ledger_okf.rs with 12 proptest properties pinning the session-ledger OKF SSOT: * OkfDocument::new(b, c) always produces okf = "1.0". * OkfDocument::new(b, c) propagates bundle.source_id into source_id and provenance.source_id. * OkfDocument::new(b, c) propagates c into provenance.corpus. * OkfDocument::new(b, c) starts with empty entities, relations, tags. * validate_okf_document reports exactly one unsupported_version error per non-"1.0" okf (with offending version in message). * validate_okf_document reports exactly one source_id_mismatch error per provenance/source mismatch. * Duplicate entity ids each surface a duplicate_entity_id error. * Dangling relation source / target surface their respective errors. * Every OkfValidationError carries non-empty field / code / message. First property test to exercise session_ledger (the core domain crate) from sl-viewer's test harness, pivoting the bounded lane beyond the viewer-only surface. Updates WBS-6.2 evidence list, TRACEABILITY.json, and CHANGELOG. * test(viewer): session-ledger worklog projector proptest surface (WBS-6.2 #460) Adds crates/sl-viewer/tests/properties_session_ledger_worklog.rs with 11 proptest properties pinning the session-ledger worklog projector (crash-recovery / lost-work pipeline): * Empty sessions project None. * Final Role::User turn -> AwaitingAssistantResponse. * Final Role::Tool / Role::Subagent -> InterruptedExecution. * Final assistant turn with one of the 9 documented completion markers (complete / completed / done / [completed] / <completed> / status: complete / status: completed / task complete / task completed) projects None. * Final assistant turn without any marker projects as MissingCompletionMarker. * UnfinishedWorkItem carries the originating session id, corpus, and message_count. * summary never exceeds 241 chars and is single-line. * project_unfinished_work returns one item per unfinished session in input order and is deterministic. * WorklogProjection::from_session carries message_count and matches detect_unfinished exactly. Updates WBS-6.2 evidence list, TRACEABILITY.json, and CHANGELOG. * test(viewer): session-ledger OKF export adapter proptest surface (WBS-6.2 #461) Adds crates/sl-viewer/tests/properties_session_ledger_export.rs with 8 proptest properties pinning session_ledger::export_to_okf (the OKF v1 export pipeline entry point): * export_to_okf always produces okf = "1.0" and propagates bundle.source_id into source_id + provenance.source_id. * export_to_okf propagates the corpus arg into provenance.corpus. * Empty bundles yield zero entities / relations / tags. * Every exported document passes validate_okf_document. * export_to_okf is deterministic across calls. * Intent bundles emit exactly one goal entity (label = goal), one acceptance entity per acceptance signal, one constraint entity per constraint. * Context bundles emit exactly one resource entity when cwd is present. * Acceptance bundles emit exactly one gate entity with label = "resume-gate" and properties.ready = true / scope_sized = true. * The exporter never produces duplicate entity ids across mixed intent / context / acceptance / contract bundles. Updates WBS-6.2 evidence list, TRACEABILITY.json, and CHANGELOG. * test(viewer): session-ledger distill compiler proptest surface (WBS-6.2 #462) Adds crates/sl-viewer/tests/properties_session_ledger_distill.rs with 9 proptest properties pinning session_ledger::distill::compile and compile_and_store: * compile(session) always produces a bundle whose source_id equals session.id. * compile(session) always produces an injectable bundle (carries an Acceptance slice) — the load-bearing contract for resume. * compile(session) always emits one slice for every documented kind (Acceptance / Intent / Context / Contract / Provenance / Worklog) — even when the session is empty. * compile(session) always returns a bundle whose total_token_estimate() equals the sum of per-slice token_estimate values. * compile(session) is deterministic across calls. * The Worklog slice body deserializes to a WorklogProjection whose message_count equals session.messages.len(). * compile_and_store returns an injectable bundle with the input source_id. * compile_and_store writes exactly 3 episodic memories (intent / contract / context) to the memory store. * compile_and_store is deterministic across fresh stores. Updates WBS-6.2 evidence list, TRACEABILITY.json, and CHANGELOG. * test(viewer): session-ledger heuristic intent extractor proptest surface (WBS-6.2 #463) Adds crates/sl-viewer/tests/properties_session_ledger_intent.rs with 10 proptest properties pinning session_ledger::distill::extractor::HeuristicIntentExtractor::extract_intent (the P1 SSOT for what the user wants — drives resume prompt, search index, and wiki/docs view): * user_turn_count always equals the count of Role::User messages and ignores Assistant / Subagent / Tool / System messages. * Empty sessions produce an empty Intent. * Repeated acceptance / constraint patterns are deduplicated. * Every documented acceptance pattern (16) and every documented constraint pattern (19) is recognized in any user message. * Labeled Goal: / Objective: / Task: lines win over preamble. * Labeled Constraint: / Requirement: / Boundary: lines carry their full text. * extract_intent is deterministic across calls. 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 color-token mismatches✅ Fewer missing CSS variables✅ More reliable light and dark theme behavior💡 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.