feat: Add dynamic upper bound for speed test gauge based on historical data - #628
Merged
Merged
Conversation
- Add Article XIV: UI Kit Library Principle with mandatory UI component usage rules - Translate all remaining Chinese content in constitution.md to English - Update "Last Amended" date to 2026-02-11 Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
…ion compliance Create new Claude Code skill that automatically enforces project constitution principles during feature implementation. Key features: - Requirements clarity check before implementation starts - Integrates with brainstorming skill for unclear requirements - Enforces UI Kit Library usage with component verification - Mandates test coverage (Service ≥90%, Provider ≥85%, Overall ≥80%) - Automates testing execution (unit tests + screenshot tests) - Runs code formatting (dart format) and analysis (flutter analyze) - Validates architecture compliance (layer separation, error handling) - Provides decision trees and examples for common scenarios The skill automatically triggers on keywords like 實作, 創建, 新增, 開發, 修改, 重構, 修正, etc., ensuring consistent adherence to constitution without manual reminders. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
…l data The speed test gauge now automatically adjusts its upper limit based on historical test results, providing better visualization across different network speed ranges. Changes: - Add helper methods to calculate maximum historical speed and round to nearest hundred - Generate appropriate markers dynamically based on the upper bound - Update meterView and _startButton to use dynamic markers instead of fixed 100 Mbps limit Behavior: - No history: defaults to 100 Mbps (maintains backward compatibility) - With history: uses maximum speed from history, rounded up to nearest hundred (e.g., 345 Mbps → 400 Mbps upper bound) - Markers are distributed appropriately for different speed ranges (100-200, 200-500, 500-1000, 1000+ Mbps) Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Review Summary by QodoAdd dynamic speed test gauge scaling and constitution compliance automation
WalkthroughsDescription• Add dynamic gauge upper bound calculation based on historical speed test data • Implement adaptive marker generation for different speed ranges (100-1000+ Mbps) • Replace fixed 100 Mbps limit with intelligent scaling using maximum historical speeds • Add comprehensive constitution compliance skill for automated feature implementation • Translate constitution.md to English and add UI Kit Library principle (Article XIV) Diagramflowchart LR
A["Historical Speed Data"] -->|Calculate Max Speed| B["Round to Nearest Hundred"]
B -->|Determine Range| C["Generate Adaptive Markers"]
C -->|Apply to Gauge| D["Dynamic Upper Bound Gauge"]
E["Constitution Requirements"] -->|Verify Compliance| F["Automated Implementation Skill"]
F -->|Enforce Rules| G["Code Quality & Testing"]
File Changes1. lib/page/health_check/shared_widgets/speed_test_widget.dart
|
Code Review by Qodo
1. Non-English text in SKILL.md
|
![qodo-code-review[bot]](https://avatars.githubusercontent.com/in/484649?s=60&v=4){kind=small}
| @@ -0,0 +1,384 @@ | |||
| --- | |||
| name: implement-feature-with-checks | |||
| description: Automatically enforce constitution compliance, UI Kit usage, testing, and code formatting when implementing features with CLEAR and SPECIFIC requirements. Use AFTER brainstorming or requirements clarification is complete, when user provides concrete implementation details. Do NOT use if requirements are vague or unclear - suggest brainstorming first. Trigger keywords (English) - implement, create, add, build, develop, make, modify, update, change, refactor, fix, repair. Trigger keywords (Chinese) - 實作, 創建, 新增, 開發, 製作, 修改, 更新, 改動, 重構, 修正, 修復, 修好. | |||
There was a problem hiding this comment.
1. Non-english text in skill.md 📘 Rule violation ✓ Correctness
The newly added .claude skill documentation contains Traditional Chinese text, violating the requirement that repository comments/documentation be English-only. This reduces consistency and may hinder comprehension for English-only reviewers.
Agent Prompt
## Issue description
The new `.claude/skills/implement-feature-with-checks/SKILL.md` file contains Traditional Chinese text (e.g., trigger keywords and example phrases). Compliance requires repository comments/documentation to be English-only.
## Issue Context
This PR introduces a new skill documentation file. It should be consistent and universally understandable per the English-only requirement.
## Fix Focus Areas
- .claude/skills/implement-feature-with-checks/SKILL.md[1-384]
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
Comment on lines
+169
to
+182
| } else if (upperBound <= 1000) { | ||
| // 500-1000 Mbps range | ||
| // Generate markers at 100 Mbps intervals, with an extra marker at 750 | ||
| final markers = <double>[0]; | ||
| for (double i = 100; i <= 500; i += 100) { | ||
| markers.add(i); | ||
| } | ||
| markers.add(750); | ||
| if (upperBound != 1000) { | ||
| markers.add(upperBound); | ||
| } else { | ||
| markers.add(1000); | ||
| } | ||
| return markers; |
There was a problem hiding this comment.
2. Unsorted gauge markers 🐞 Bug ✓ Correctness
For upperBound values between 600–700 Mbps, _generateMarkers() adds a 750 marker unconditionally, producing markers that exceed upperBound and are not sorted. This can cause incorrect AppGauge rendering and may trigger assertions/logic errors if the gauge assumes markers are within range and ascending.
Agent Prompt
### Issue description
`_generateMarkers()` can return marker values larger than `upperBound` and out-of-order (e.g., `upperBound=600` yields `... 750, 600`). This can break gauge rendering/logic.
### Issue Context
`upperBound` is computed by rounding historical max speed up to the nearest hundred, so values like 600 and 700 are expected.
### Fix Focus Areas
- lib/page/health_check/shared_widgets/speed_test_widget.dart[169-182]
- lib/page/health_check/shared_widgets/speed_test_widget.dart[113-134]
### Implementation notes
- Only add `750` when `upperBound >= 750`.
- Always append `upperBound` as the maximum marker.
- Optionally: `final sorted = {...markers}.toList()..sort();` and ensure all markers `<= upperBound`.
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
Fix marker generation bug in _generateMarkers for 500-1000 Mbps range. Previously, when upperBound was less than 750 (e.g., 600 or 700), the method unconditionally added 750 marker, resulting in unsorted list that exceeded the upper bound. Changes: - Add conditional check before adding 750 marker (only if upperBound >= 750) - Ensure markers list maintains ascending order - Ensure all markers stay within upperBound Before: upperBound=600 → [0, 100, 200, 300, 400, 500, 750, 600] (unsorted) After: upperBound=600 → [0, 100, 200, 300, 400, 500, 600] (sorted) Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
PeterJhongLinksys
requested review from
AustinChangLinksys and
HankYuLinksys
February 11, 2026 11:01
Extract the 4 gauge calculation methods from SpeedTestWidget into a reusable SpeedTestGaugeUtils class with comprehensive unit tests. Changes: - Create SpeedTestGaugeUtils class with 4 static methods: - calculateMaxHistoricalSpeed(): Find max speed from history - roundUpToHundred(): Round up to nearest hundred - calculateGaugeUpperBound(): Calculate dynamic upper bound - generateMarkers(): Generate appropriate markers for different ranges - Add 39 comprehensive unit tests covering all edge cases - Refactor SpeedTestWidget to use the new utils class - Remove 4 private methods from SpeedTestWidget (130 lines) Benefits: - Improved testability: 100% test coverage for calculation logic - Better code organization: Follows project pattern (feature/utils/) - Reusability: Utils can be used in other contexts - Maintainability: Centralized logic with clear documentation Testing: - All 39 utils tests pass - All 23 existing health_check tests pass (regression) - Static analysis clean Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
AustinChangLinksys
approved these changes
Feb 12, 2026
AustinChangLinksys
left a comment
AustinChangLinksys
left a comment
Collaborator
There was a problem hiding this comment.
looks good to me
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
The speed test gauge now automatically adjusts its upper limit based on historical test results, providing better visualization across different network speed ranges.
Changes
meterViewand_startButtonmethods to use dynamic markers instead of fixed 100 Mbps limitBehavior
Testing
Files Changed
lib/page/health_check/shared_widgets/speed_test_widget.dart(+140, -15)🤖 Generated with Claude Code