@zenuml/core 3.46.2 → 3.46.4

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@zenuml/core",
3
- "version": "3.46.2",
3
+ "version": "3.46.4",
4
4
  "private": false,
5
5
  "license": "MIT",
6
6
  "repository": {
@@ -1,96 +0,0 @@
1
- # [COMPONENT NAME] - Component Context (Tier 2)
2
-
3
- > **Note**: This is component-specific context. See root **CLAUDE.md** for master project context and coding standards.
4
-
5
- ## Purpose
6
- [Brief description of this component's role in the system. What problem does it solve and how does it fit into the overall architecture?]
7
-
8
- ## Current Status: [Status Description] ✅/🚧/📋
9
- [Current implementation state, what's working, what's in progress, and key milestones achieved]
10
-
11
- ## Component-Specific Development Guidelines
12
- - **[Technology/Framework]**: [Specific technology requirements for this component]
13
- - **[Architecture Pattern]**: [Component-specific architectural approach]
14
- - **[Code Organization]**: [How code should be structured within this component]
15
- - **[Integration Patterns]**: [How this component integrates with others]
16
- - **[Quality Standards]**: [Component-specific quality requirements]
17
-
18
- ## Key Component Structure
19
-
20
- ### Core Modules (`[path]/`)
21
- - **[module1]/** - [Purpose and key functionality]
22
- - **[file1].[ext]** - [Specific file purpose and key features]
23
- - **[file2].[ext]** - [Specific file purpose and key features]
24
- - **[module2]/** - [Purpose and key functionality]
25
- - **[module3]/** - [Purpose and key functionality]
26
-
27
- ### [Secondary Structure] (`[path]/`)
28
- - **[component].[ext]** - [Component purpose and architecture pattern]
29
- - **[utilities].[ext]** - [Utility functions and helpers]
30
- - **[config].[ext]** - [Configuration and settings management]
31
-
32
- ### [Integration Layer] (`[path]/`)
33
- - **[integration1].[ext]** - [External service integration patterns]
34
- - **[integration2].[ext]** - [Inter-component communication]
35
-
36
- ## Implementation Highlights
37
-
38
- ### [Key Feature 1]
39
- - **[Technical Implementation]**: [How this feature is implemented]
40
- - **[Architecture Decision]**: [Why this approach was chosen]
41
- - **[Performance Considerations]**: [Optimization details]
42
- - **[Integration Points]**: [How it connects to other components]
43
-
44
- ### [Key Feature 2]
45
- - **[Implementation Pattern]**: [Technical implementation approach]
46
- - **[Quality Measures]**: [Testing, monitoring, error handling]
47
- - **[Scalability Considerations]**: [How it handles growth/load]
48
-
49
- ### [Key Feature 3]
50
- - **[Technical Details]**: [Implementation specifics]
51
- - **[Dependencies]**: [External dependencies and integration points]
52
- - **[Configuration]**: [How it's configured and customized]
53
-
54
- ## Critical Implementation Details
55
-
56
- ### [Technical Pattern 1]
57
- **[Pattern Description]**: [What problem this pattern solves]
58
-
59
- ```[language]
60
- // Example implementation showing the pattern
61
- [code example demonstrating the critical implementation]
62
- ```
63
-
64
- ### [Technical Pattern 2]
65
- **[Architecture Decision]**: [Why this approach was chosen]
66
-
67
- ```[language]
68
- // Code example showing architecture implementation
69
- [code example demonstrating the architecture]
70
- ```
71
-
72
- ### [Integration Pattern]
73
- **[Integration Description]**: [How this component integrates with others]
74
-
75
- ```[language]
76
- // Integration implementation example
77
- [code example showing integration patterns]
78
- ```
79
-
80
- ## Development Notes
81
-
82
- ### [Current Challenges]
83
- - **[Challenge 1]**: [Description and current approach]
84
- - **[Challenge 2]**: [Description and mitigation strategy]
85
-
86
- ### [Future Considerations]
87
- - **[Enhancement 1]**: [Planned improvement and rationale]
88
- - **[Enhancement 2]**: [Future architectural evolution]
89
-
90
- ### [Performance Metrics]
91
- - **[Key Metric 1]**: [Current performance and targets]
92
- - **[Key Metric 2]**: [Monitoring and optimization approach]
93
-
94
- ---
95
-
96
- *This component documentation provides context for AI-assisted development within [COMPONENT NAME]. For system-wide patterns and standards, reference the master CLAUDE.md file.*
@@ -1,162 +0,0 @@
1
- # [FEATURE NAME] Documentation (Tier 3)
2
-
3
- *This file documents [feature/module] patterns, architectural decisions, and implementations within [component name].*
4
-
5
- ## [Feature] Architecture Overview
6
-
7
- ### [Architecture Decision Title]
8
-
9
- **Context**: [Situation that led to this architectural decision]
10
-
11
- **Decision**: [What was decided and implemented]
12
-
13
- **Reasoning**:
14
- - **[Benefit 1]**: [Why this approach provides this benefit]
15
- - **[Benefit 2]**: [Technical or business advantage]
16
- - **[Benefit 3]**: [Performance or maintainability benefit]
17
- - **[Benefit 4]**: [Developer experience or operational benefit]
18
-
19
- **Consequences**:
20
- - [Positive outcome from this decision]
21
- - [Technical improvement achieved]
22
- - [Operational or maintenance benefit]
23
- - [User experience enhancement]
24
-
25
- ## [Feature] Implementation Patterns
26
-
27
- ### [Implementation Pattern 1]
28
-
29
- **File Organization**:
30
- ```
31
- [feature-directory]/
32
- ├── [file1].[ext] # [Purpose and responsibility]
33
- ├── [file2].[ext] # [Purpose and responsibility]
34
- ├── [file3].[ext] # [Purpose and responsibility]
35
- └── [file4].[ext] # [Purpose and responsibility]
36
- ```
37
-
38
- **Architecture Benefits**:
39
- - **[Benefit 1]**: [How this organization provides this benefit]
40
- - **[Benefit 2]**: [Technical advantage of this structure]
41
- - **[Benefit 3]**: [Maintainability or scalability benefit]
42
- - **[Benefit 4]**: [Developer experience improvement]
43
-
44
- ### [Implementation Pattern 2]
45
-
46
- **Architecture Decision**: [Technical approach taken]
47
-
48
- **Context**: [Background and requirements that led to this approach]
49
-
50
- **Decision**: [Specific implementation choice made]
51
-
52
- **Reasoning**:
53
- - **[Technical Reason]**: [Why this was the best technical choice]
54
- - **[Performance Reason]**: [Performance benefits]
55
- - **[Maintainability Reason]**: [Long-term maintenance benefits]
56
- - **[Integration Reason]**: [How it integrates with other components]
57
-
58
- **Implementation Details**:
59
- ```[language]
60
- // [Description of what this code demonstrates]
61
- [detailed code example showing the implementation pattern]
62
- ```
63
-
64
- ### [Implementation Pattern 3]
65
-
66
- **[Pattern Name]**: [Description of the pattern]
67
-
68
- ```[language]
69
- // [Code example title]
70
- [comprehensive code example showing the pattern in action]
71
- ```
72
-
73
- **Implementation Benefits**:
74
- - **[Benefit 1]**: [Specific advantage this implementation provides]
75
- - **[Benefit 2]**: [Performance or reliability improvement]
76
- - **[Benefit 3]**: [Developer experience enhancement]
77
-
78
- ## [Technical Domain] Implementation
79
-
80
- ### [Technical Feature 1]
81
-
82
- **[Feature Description]**: [What this feature does and why it's important]
83
-
84
- **Architecture Pattern**:
85
- ```[language]
86
- // [Description of the architectural approach]
87
- [code example demonstrating the architecture]
88
- ```
89
-
90
- **Key Implementation Details**:
91
- - **[Detail 1]**: [Important implementation consideration]
92
- - **[Detail 2]**: [Technical constraint or optimization]
93
- - **[Detail 3]**: [Integration or performance consideration]
94
-
95
- ### [Technical Feature 2]
96
-
97
- **Implementation Approach**: [How this feature is implemented]
98
-
99
- ```[language]
100
- // [Code example description]
101
- [detailed implementation example]
102
- ```
103
-
104
- **Technical Considerations**:
105
- - **[Consideration 1]**: [Important technical factor]
106
- - **[Consideration 2]**: [Performance or scalability factor]
107
- - **[Consideration 3]**: [Maintenance or testing consideration]
108
-
109
- ## [Integration/Communication] Patterns
110
-
111
- ### [Integration Pattern 1]
112
-
113
- **Context**: [When and why this integration pattern is used]
114
-
115
- **Implementation**:
116
- ```[language]
117
- // [Integration example description]
118
- [code showing integration implementation]
119
- ```
120
-
121
- **Benefits**:
122
- - **[Integration Benefit 1]**: [How this improves system integration]
123
- - **[Integration Benefit 2]**: [Performance or reliability improvement]
124
-
125
- ### [Integration Pattern 2]
126
-
127
- **Pattern Description**: [What problem this integration pattern solves]
128
-
129
- ```[language]
130
- // [Integration code example]
131
- [implementation showing integration pattern]
132
- ```
133
-
134
- ## Performance & Optimization Details
135
-
136
- ### [Performance Optimization 1]
137
- **Optimization**: [What was optimized and how]
138
- - **Before**: [Previous performance characteristics]
139
- - **After**: [Improved performance metrics]
140
- - **Implementation**: [How the optimization was achieved]
141
-
142
- ### [Performance Optimization 2]
143
- **Technical Improvement**: [Specific performance enhancement]
144
- - **Impact**: [Measurable improvement achieved]
145
- - **Method**: [Technical approach used]
146
- - **Trade-offs**: [Any compromises made for the optimization]
147
-
148
- ## Error Handling & Edge Cases
149
-
150
- ### [Error Scenario 1]
151
- **Scenario**: [What error condition this handles]
152
- **Handling**: [How the error is detected and managed]
153
- **Recovery**: [How the system recovers from this error]
154
-
155
- ### [Error Scenario 2]
156
- **Edge Case**: [Unusual condition that needs handling]
157
- **Solution**: [How the implementation handles this case]
158
- **Validation**: [How this handling is tested or verified]
159
-
160
- ---
161
-
162
- *This feature documentation provides detailed implementation context for AI-assisted development. For broader component context, see the component-level CONTEXT.md file.*
package/docs/README.md DELETED
@@ -1,207 +0,0 @@
1
- # Documentation System Guide
2
-
3
- This guide explains how the 3-tier documentation architecture powers the Claude Code Development Kit and why it provides superior results compared to traditional documentation approaches.
4
-
5
- ## Critical Foundation Files
6
-
7
- Two files form the cornerstone of the entire documentation system:
8
-
9
- 1. **docs-overview.md** - The central routing guide that directs AI agents to appropriate documentation based on task complexity. This file maps your entire documentation structure and enables intelligent context loading.
10
-
11
- 2. **project-structure.md** - The comprehensive overview of your project's complete file structure and technology stack. This file is required reading for all AI agents and must be attached to Gemini consultations.
12
-
13
- These foundation files ensure AI agents always have the essential context needed to understand your project and navigate to relevant documentation.
14
-
15
- ## Why the 3-Tier System
16
-
17
- ### Traditional Documentation Problems
18
-
19
- Standard documentation approaches create friction for AI-assisted development:
20
-
21
- - **Context Overload** - AI agents must process entire documentation sets for simple tasks
22
- - **Maintenance Burden** - Every code change cascades to multiple documentation locations
23
- - **Stale Content** - Documentation diverges from implementation reality
24
- - **No AI Optimization** - Human-readable formats lack structure for machine processing
25
-
26
- ### The 3-Tier Solution
27
-
28
- The kit solves these problems through hierarchical organization:
29
-
30
- **Tier 1: Foundation (Rarely Changes)**
31
- - Project-wide standards, architecture decisions, technology stack
32
- - Auto-loads for every AI session
33
- - Provides consistent baseline without redundancy
34
- - Uses CLAUDE.md as the master context file
35
-
36
- **Tier 2: Component (Occasionally Changes)**
37
- - Component boundaries, architectural patterns, integration points
38
- - Loads only when working within specific components
39
- - Isolates architectural decisions from implementation details
40
- - Uses CONTEXT.md files at component roots
41
-
42
- **Tier 3: Feature (Frequently Changes)**
43
- - Implementation specifics, technical details, local patterns
44
- - Co-located with code for immediate updates
45
- - Minimizes documentation cascade when code changes
46
- - Uses CONTEXT.md files within feature directories
47
-
48
- ## Benefits vs Traditional Systems
49
-
50
- ### 1. Intelligent Context Loading
51
-
52
- **Traditional**: AI loads entire documentation corpus regardless of task
53
- **3-Tier**: Commands load only relevant tiers based on complexity
54
-
55
- Example:
56
- - Simple query → Tier 1 only (minimal tokens)
57
- - Component work → Tier 1 + relevant Tier 2
58
- - Deep implementation → All relevant tiers
59
-
60
- ### 2. Maintenance Efficiency
61
-
62
- **Traditional**: Update multiple documents for each change
63
- **3-Tier**: Updates isolated to appropriate tier
64
-
65
- Example:
66
- - API endpoint change → Update only Tier 3 API documentation
67
- - New component → Add Tier 2 documentation, Tier 1 unchanged
68
- - Coding standard → Update only Tier 1, applies everywhere
69
-
70
- ### 3. AI Performance Optimization
71
-
72
- **Traditional**: AI struggles to find relevant information
73
- **3-Tier**: Structured hierarchy guides AI to precise context
74
-
75
- The system provides:
76
- - Clear routing logic for agent navigation
77
- - Predictable documentation locations
78
- - Efficient token usage through targeted loading
79
-
80
- ## Integration with Kit Components
81
-
82
- ### Command Integration
83
-
84
- Commands leverage the 3-tier structure for intelligent operation:
85
-
86
- ```
87
- Command Execution → Analyze Task Complexity → Load Appropriate Tiers
88
-
89
- Simple: Tier 1 only
90
- Component: Tiers 1-2
91
- Complex: All relevant tiers
92
- ```
93
-
94
- ### MCP Server Integration
95
-
96
- External AI services receive proper context through the tier system:
97
-
98
- - **Gemini Consultations** - Auto-attach `project-structure.md` (Tier 1)
99
- - **Context7 Lookups** - Happen within established project context
100
- - **Recommendations** - Align with documented architecture
101
-
102
- ### Multi-Agent Routing
103
-
104
- The documentation structure determines agent behavior:
105
-
106
- - Number of agents spawned based on tiers involved
107
- - Each agent receives targeted documentation subset
108
- - Parallel analysis without context overlap
109
-
110
- ## Key Files and Their Roles
111
-
112
- ### Foundation Files (ai-context/)
113
-
114
- **docs-overview.md**
115
- - Template for implementing 3-tier documentation
116
- - Maps documentation structure for AI navigation
117
- - [View Template](ai-context/docs-overview.md)
118
-
119
- **project-structure.md**
120
- - Complete technology stack and file organization
121
- - Required reading for all AI agents
122
- - Auto-attaches to Gemini consultations
123
- - [View Template](ai-context/project-structure.md)
124
-
125
- **system-integration.md**
126
- - Cross-component communication patterns
127
- - Integration architectures for multi-agent analysis
128
- - [View Template](ai-context/system-integration.md)
129
-
130
- **deployment-infrastructure.md**
131
- - Infrastructure patterns and constraints
132
- - Deployment context for AI recommendations
133
- - [View Template](ai-context/deployment-infrastructure.md)
134
-
135
- **handoff.md**
136
- - Session continuity between AI interactions
137
- - Task state preservation
138
- - [View Template](ai-context/handoff.md)
139
-
140
- ### Context Templates
141
-
142
- **CLAUDE.md** (Tier 1)
143
- - Master AI context with coding standards
144
- - Project-wide instructions and patterns
145
- - [View Template](CLAUDE.md)
146
-
147
- **CONTEXT-tier2-component.md**
148
- - Component-level architectural context
149
- - [View Template](CONTEXT-tier2-component.md)
150
-
151
- **CONTEXT-tier3-feature.md**
152
- - Feature-specific implementation details
153
- - [View Template](CONTEXT-tier3-feature.md)
154
-
155
- ## Implementation Strategy
156
-
157
- ### 1. Start with Templates
158
-
159
- Use provided templates as foundation:
160
- - Copy and customize for your project
161
- - Maintain consistent structure
162
- - Focus on AI-consumable formatting
163
-
164
- ### 2. Follow Natural Boundaries
165
-
166
- Let your architecture guide tier placement:
167
- - Stable decisions → Tier 1
168
- - Component design → Tier 2
169
- - Implementation details → Tier 3
170
-
171
- ### 3. Co-locate Documentation
172
-
173
- Place CONTEXT.md files with related code:
174
- ```
175
- backend/
176
- ├── CONTEXT.md # Backend architecture (Tier 2)
177
- └── src/
178
- └── api/
179
- └── CONTEXT.md # API implementation (Tier 3)
180
- ```
181
-
182
- ### 4. Maintain Hierarchy
183
-
184
- Ensure clear relationships:
185
- - Tier 3 references Tier 2 patterns
186
- - Tier 2 follows Tier 1 standards
187
- - No circular dependencies
188
-
189
- ### 5. Use Documentation Commands
190
-
191
- The kit provides commands to manage documentation:
192
- - **`/create-docs`** - Generate initial documentation structure for projects without existing docs
193
- - **`/update-docs`** - Regenerate and update documentation after code changes to keep everything current
194
-
195
- ## Measuring Success
196
-
197
- The 3-tier system succeeds when:
198
-
199
- 1. **AI agents find context quickly** - No searching through irrelevant documentation
200
- 2. **Updates stay localized** - Changes don't cascade unnecessarily
201
- 3. **Documentation stays current** - Co-location ensures updates happen
202
- 4. **Commands work efficiently** - Appropriate context loads automatically
203
- 5. **MCP servers provide relevant advice** - External AI understands your project
204
-
205
- ---
206
-
207
- *Part of the Claude Code Development Kit - see [main documentation](../README.md) for complete system overview.*
Binary file
@@ -1,17 +0,0 @@
1
- The `module` field is not officially defined by Node.js and support is not planned.
2
- Instead, the Node.js community settled on package `exports` which they believe is
3
- more versatile.
4
-
5
- For practical reasons JavaScript bundlers will continue support the `module` field.
6
- The esbuild docs [explain](https://esbuild.github.io/api/#main-fields)
7
- when to use `module` as well as related fields like `main` and `browser`.
8
-
9
-
10
- * `main` is the standard field for all packages that are mean to be used with node.
11
- It is reasonable to expect that the file path in this field is a valid CommonJS module.
12
- * `module` is a non-standard field that is used to integrate ECMAScript modules into
13
- node. It is reasonable to expect that the file path in this field is an ECMAScript module (esm).
14
-
15
- For @zenuml/core, the `main` field is set to `dist/zenuml.js` and the `module` field
16
- is set to `dist/zenuml.esm.js`.
17
-
@@ -1,79 +0,0 @@
1
- # API Performance Issue - Example Template
2
-
3
- ## Issue Description
4
-
5
- Describe the specific performance issue or bug that needs to be addressed. Include symptoms, affected features, and user impact.
6
-
7
- Example: "API endpoint `/api/data/process` has intermittent high latency (>5 seconds) under normal load conditions, causing user timeout errors."
8
-
9
- ## Root Cause
10
-
11
- Detailed analysis of what's causing the issue. Include:
12
- - Technical root cause
13
- - Contributing factors
14
- - System conditions that trigger the issue
15
-
16
- Example: "Database query optimization needed for complex joins. Current query scans entire table without proper indexing."
17
-
18
- ## Impact Assessment
19
-
20
- - **Severity**: Critical/High/Medium/Low
21
- - **Affected Users**: Percentage or number of users impacted
22
- - **Business Impact**: Revenue, user experience, or operational impact
23
- - **Workarounds**: Any temporary solutions currently in place
24
-
25
- ## Proposed Solution
26
-
27
- ### Technical Approach
28
- Detailed technical solution including:
29
- - Code changes required
30
- - Architecture modifications
31
- - Database schema updates
32
- - Performance improvements expected
33
-
34
- ### Implementation Plan
35
- 1. **Phase 1**: Initial fixes (timeline)
36
- 2. **Phase 2**: Optimization improvements (timeline)
37
- 3. **Phase 3**: Monitoring and validation (timeline)
38
-
39
- ## Testing Strategy
40
-
41
- - **Unit Tests**: Specific test cases to validate the fix
42
- - **Integration Tests**: End-to-end testing scenarios
43
- - **Performance Tests**: Load testing and benchmarking
44
- - **Regression Tests**: Ensure no existing functionality breaks
45
-
46
- ## Related Files
47
-
48
- List all files that need to be modified:
49
- - `src/api/routes/data.py` - Main endpoint logic
50
- - `src/database/models.py` - Database model updates
51
- - `src/utils/query_optimizer.py` - Query optimization utilities
52
- - `tests/test_api_performance.py` - Performance test suite
53
-
54
- ## References
55
-
56
- - [External documentation or APIs]
57
- - [Related GitHub issues or PRs]
58
- - [Performance benchmarking results]
59
- - [Stack Overflow discussions or solutions]
60
-
61
- ## Status
62
-
63
- - [ ] **Open** - Issue identified and documented
64
- - [ ] **In Progress** - Solution being implemented
65
- - [ ] **Testing** - Fix implemented, undergoing testing
66
- - [ ] **Fixed** - Issue resolved and deployed
67
- - [ ] **Closed** - Issue confirmed resolved in production
68
-
69
- ## Implementation Notes
70
-
71
- Track progress and implementation details:
72
- - Date started: [DATE]
73
- - Key decisions made: [DECISIONS]
74
- - Challenges encountered: [CHALLENGES]
75
- - Performance improvements achieved: [METRICS]
76
-
77
- ---
78
-
79
- *This template provides a structured approach to documenting and tracking technical issues. Customize sections based on your project's specific needs and workflow.*
@@ -1,13 +0,0 @@
1
- Error when running 'bun run build'
2
-
3
- ```shell
4
- ERROR Failed to compile with 1 error 10:15:37 AM
5
-
6
- error in ./src/components/theme-blue-river.scss
7
-
8
- Syntax Error: ModuleError: Module Error (from ./node_modules/sass-loader/dist/cjs.js):
9
- Missing binding /Users/pengxiao/workspaces/zenuml/vue-sequence/node_modules/node-sass/vendor/darwin-x64-83/binding.node
10
- Node Sass could not find a binding for your current environment: OS X 64-bit with Node.js 14.x
11
- ```
12
-
13
- Remove 'node_modules' and re-run 'bun run build' under node 14.
@@ -1,76 +0,0 @@
1
- # Running Cypress Tests Locally
2
-
3
- This document explains how to run Cypress tests locally on your machine, with a focus on ensuring color profiles match those used in GitHub Actions for consistent visual testing results.
4
-
5
- ## Running Tests
6
-
7
- You can run Cypress tests using the following commands:
8
-
9
- - Run all tests headlessly:
10
-
11
- ```bash
12
- pnpm cy
13
- ```
14
-
15
- - Run a specific test file:
16
-
17
- ```bash
18
- pnpm cypress run --spec "cypress/e2e/smoke.spec.js"
19
- ```
20
-
21
- ## Color Profile Configuration
22
-
23
- ### Why Color Profiles Matter
24
-
25
- Visual regression tests in Cypress compare screenshots pixel-by-pixel. Different color profiles can cause the same UI to render with slightly different colors, leading to false test failures. To match the GitHub Actions environment, we use the sRGB color profile.
26
-
27
- ### Automatic Configuration
28
-
29
- Our Cypress configuration automatically forces the sRGB color profile when running tests. This is configured in `cypress/plugins/index.js` with the following code:
30
-
31
- ```javascript
32
- on("before:browser:launch", (browser = {}, launchOptions) => {
33
- if (browser.family === "chromium" && browser.name !== "electron") {
34
- launchOptions.args.push("--force-color-profile=srgb");
35
- }
36
- });
37
- ```
38
-
39
- ### Configuring macOS Color Profile
40
-
41
- For the most consistent results, you should also configure your macOS system to use the sRGB color profile:
42
-
43
- 1. Open System Preferences (or System Settings on newer macOS versions)
44
- 2. Go to "Displays"
45
- 3. Select the "Color" tab
46
- 4. Click "Calibrate" to open the Display Calibrator Assistant
47
- 5. Follow the wizard and when prompted for a color profile, select "sRGB"
48
- 6. Complete the calibration and save the profile
49
-
50
- Alternatively, you can directly select an existing sRGB profile:
51
-
52
- 1. Open System Preferences > Displays > Color
53
- 2. From the list of color profiles, select "sRGB IEC61966-2.1" or a similar sRGB profile
54
- 3. Click "Apply"
55
-
56
- ## Troubleshooting Visual Test Failures
57
-
58
- If you encounter visual test failures despite using the sRGB profile:
59
-
60
- 1. Check that your display brightness is set to a consistent level
61
- 2. Ensure you're using the same browser version as GitHub Actions (Chrome)
62
- 3. Verify that your OS theme/appearance settings match the CI environment (light mode is recommended)
63
- 4. If necessary, adjust the threshold in the image snapshot configuration:
64
-
65
- ```javascript
66
- cy.document().toMatchImageSnapshot({
67
- imageConfig: { threshold: 0.012 }, // Increase this value if needed
68
- capture: "viewport",
69
- });
70
- ```
71
-
72
- ## Additional Resources
73
-
74
- - [Cypress Image Snapshot Documentation](https://github.com/jaredpalmer/cypress-image-snapshot)
75
- - [Chrome Command Line Switches](https://peter.sh/experiments/chromium-command-line-switches/)
76
- - [macOS Color Management Guide](https://support.apple.com/guide/mac-help/calibrate-your-display-mchlp2920/mac)