@zenuml/core 3.46.3 → 3.46.5
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/.claude/skills/babysit-pr/SKILL.md +203 -0
- package/.claude/skills/babysit-pr/agents/openai.yaml +7 -0
- package/.claude/skills/dia-scoring/SKILL.md +1 -1
- package/.claude/skills/land-pr/SKILL.md +27 -5
- package/.claude/skills/propagate-core-release/SKILL.md +200 -0
- package/.claude/skills/propagate-core-release/agents/openai.yaml +7 -0
- package/.claude/skills/propagate-core-release/references/downstreams.md +41 -0
- package/.claude/skills/ship-branch/SKILL.md +13 -0
- package/dist/stats.html +1 -1
- package/dist/zenuml.esm.mjs +3688 -3693
- package/dist/zenuml.js +69 -69
- package/docs/superpowers/plans/2026-03-27-e2e-test-reorg.md +698 -0
- package/{cy → e2e/data}/compare-cases.js +70 -37
- package/{cy/smoke-editable-label.html → e2e/fixtures/editable-label.html} +1 -1
- package/{cy/editable-span-test.html → e2e/fixtures/editable-span.html} +1 -1
- package/e2e/fixtures/fixture.html +31 -0
- package/{cy → e2e/tools}/canonical-history.html +1 -1
- package/{cy → e2e/tools}/compare-case.html +3 -3
- package/{cy → e2e/tools}/compare.html +2 -2
- package/{cy → e2e/tools}/native-diff-ext/content.js +2 -2
- package/firebase-debug.log +108 -0
- package/index.html +2 -2
- package/mermaid-zenuml-async-spa-auth.png +0 -0
- package/mermaid-zenuml-async-spa-auth.snapshot.md +96 -0
- package/package.json +1 -1
- package/scripts/analyze-compare-case/collect-data.mjs +1 -1
- package/scripts/analyze-compare-case.mjs +1 -1
- package/skills/dia-scoring/SKILL.md +1 -1
- package/vite.config.ts +5 -5
- package/cy/async-message-1.html +0 -32
- package/cy/async-message-2.html +0 -46
- package/cy/async-message-3.html +0 -41
- package/cy/creation-rtl.html +0 -28
- package/cy/defect-406-alt-under-creation.html +0 -40
- package/cy/demo1.html +0 -28
- package/cy/demo3.html +0 -28
- package/cy/demo4.html +0 -28
- package/cy/element-report.html +0 -705
- package/cy/fragments-with-return.html +0 -35
- package/cy/icons-test.html +0 -29
- package/cy/if-fragment.html +0 -28
- package/cy/legacy-vs-html.html +0 -291
- package/cy/named-parameters.html +0 -30
- package/cy/nested-interaction-with-fragment.html +0 -34
- package/cy/nested-interaction-with-outbound.html +0 -34
- package/cy/parity-test.html +0 -122
- package/cy/return-in-nested-if.html +0 -29
- package/cy/return.html +0 -38
- package/cy/self-sync-message-at-root.html +0 -28
- package/cy/smoke-creation.html +0 -26
- package/cy/smoke-fragment-issue.html +0 -36
- package/cy/smoke-fragment.html +0 -42
- package/cy/smoke-interaction.html +0 -34
- package/cy/smoke.html +0 -40
- package/cy/theme-default-test.html +0 -28
- package/cy/vertical-1.html +0 -25
- package/cy/vertical-10.html +0 -33
- package/cy/vertical-11.html +0 -29
- package/cy/vertical-2.html +0 -23
- package/cy/vertical-3.html +0 -37
- package/cy/vertical-4.html +0 -42
- package/cy/vertical-5.html +0 -40
- package/cy/vertical-6.html +0 -29
- package/cy/vertical-7.html +0 -27
- package/cy/vertical-8.html +0 -32
- package/cy/vertical-9.html +0 -25
- package/cy/xss.html +0 -21
- package/docs/CONTEXT-tier2-component.md +0 -96
- package/docs/CONTEXT-tier3-feature.md +0 -162
- package/docs/README.md +0 -207
- package/docs/handling-starter.png +0 -0
- package/docs/module-vs-main-in-package-json.md +0 -17
- package/docs/open-issues/example-api-performance-issue.md +0 -79
- package/docs/osx-unsupported-arm64-node12.md +0 -13
- package/docs/running-cypress-tests-locally.md +0 -76
- package/docs/ship-branch-skill-plan.md +0 -134
- package/docs/superpowers/plans/2026-03-23-svg-parity-features.md +0 -283
- package/docs/testing-minified-lib.md +0 -27
- package/docs/watch.md +0 -1
- package/docs/why-we-publish-embed-view-to-github-pages.md +0 -16
- /package/{cy → e2e/data}/diff-algorithm.js +0 -0
- /package/{cy → e2e/fixtures}/svg-test.html +0 -0
- /package/{cy → e2e/tools}/native-diff-ext/background.js +0 -0
- /package/{cy → e2e/tools}/native-diff-ext/bridge.js +0 -0
- /package/{cy → e2e/tools}/svg-preview.html +0 -0
|
@@ -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)
|