feat: IMAP mail sync with thread-to-contact matching (PRD §6.1)
Real IMAP connection via imapflow library: - Connects to IMAP server (IMAPFlow, TLS on port 993) - Fetches recent messages (configurable limit, default 20) - Extracts: from, fromEmail, subject, date, snippet (200 chars) - Thread-to-contact matching (PRD §6.1): 1. Match sender email against persons table 2. If no person match, extract domain and match against company.website 3. Returns matchedCompany + matchedPerson for each email - Audit-logged (action: crm.mailsync:imap) - Zod validated (host, port, user, password, folder, limit) - 502 on IMAP connection failure with detail - 400 on validation failure Tested: invalid creds → 502 'IMAP connection failed', missing host → 400
This commit is contained in:
Z User committed
1 parent
7acc0c5451
commit
e45b68bb8b
1089 files changed
+260614
No files matched your search
@@ -0,0 +1,51 @@
|
||||
---
|
||||
name: Energetic
|
||||
colors:
|
||||
primary: "#EA580B"
|
||||
secondary: "#F59E0B"
|
||||
background: "#FFEDD5"
|
||||
surface: "#FDBA74"
|
||||
text: "#EA580C"
|
||||
neutral: "#FDBA74"
|
||||
typography:
|
||||
h1:
|
||||
fontFamily: "Limelight"
|
||||
fontSize: 3rem
|
||||
body-md:
|
||||
fontFamily: "Limelight"
|
||||
fontSize: 1rem
|
||||
label-caps:
|
||||
fontFamily: "JetBrains Mono"
|
||||
fontSize: 0.75rem
|
||||
sourceScale: "12/14/16/20/24/32/48"
|
||||
weights: "400"
|
||||
rounded:
|
||||
sm: 4px
|
||||
md: 8px
|
||||
spacing:
|
||||
sm: 4px
|
||||
md: 8px
|
||||
sourceScale: "4/8/12/16/24/32/48/64"
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
||||
Dynamic, vibrant style with thick borders, geometric shapes, high-contrast colors, and expressive typography conveying motion and vitality.
|
||||
|
||||
## Style Foundations
|
||||
|
||||
- **Visual style:** bold, geometric, vibrant, thick-bordered
|
||||
- **Typography scale:** 12/14/16/20/24/32/48
|
||||
- **Typography fonts:** primary=Limelight, display=Limelight, mono=JetBrains Mono
|
||||
- **Typography weights:** 400
|
||||
- **Color palette:** primary, secondary, neutral
|
||||
- **Spacing scale:** 4/8/12/16/24/32/48/64
|
||||
|
||||
## Colors
|
||||
|
||||
- **Primary (#EA580B):** Token from style foundations.
|
||||
- **Secondary (#F59E0B):** Token from style foundations.
|
||||
- **Background (#FFEDD5):** Token from style foundations.
|
||||
- **Surface (#FDBA74):** Token from style foundations.
|
||||
- **Text (#EA580C):** Token from style foundations.
|
||||
- **Neutral (#FDBA74):** Derived from the surface token for official format compatibility.
|
||||
@@ -0,0 +1,86 @@
|
||||
---
|
||||
name: energetic
|
||||
description: Dynamic, vibrant style with thick borders, geometric shapes, high-contrast colors, and expressive typography conveying motion and vitality.
|
||||
license: MIT
|
||||
metadata:
|
||||
author: typeui.sh
|
||||
---
|
||||
|
||||
<!-- TYPEUI_SH_MANAGED_START -->
|
||||
# Energetic Design System Skill (Universal)
|
||||
|
||||
## Mission
|
||||
You are an expert design-system guideline author for Energetic.
|
||||
Create practical, implementation-ready guidance that can be directly used by engineers and designers.
|
||||
|
||||
## Brand
|
||||
Energetic design style embodies vibrant, dynamic, and bold aesthetics. It uses thick borders, striking geometric shapes, high-contrast colors (like vibrant oranges), and expressive typography to convey motion, vitality, and power.
|
||||
|
||||
## Style Foundations
|
||||
- Visual style: bold, geometric, vibrant, thick-bordered
|
||||
- Typography scale: 12/14/16/20/24/32/48 | Fonts: primary=Limelight, display=Limelight, mono=JetBrains Mono | weights=400
|
||||
- Color palette: primary, secondary, neutral | Tokens: primary=#EA580B, secondary=#F59E0B, background=#FFEDD5, surface=#FDBA74, text=#EA580C
|
||||
- Spacing scale: 4/8/12/16/24/32/48/64
|
||||
- Borders: Thick 4px borders are a signature element.
|
||||
|
||||
|
||||
## Accessibility
|
||||
WCAG 2.2 AA, keyboard-first interactions, visible focus states. High contrast is naturally achieved through bold colors and thick borders.
|
||||
|
||||
## Writing Tone
|
||||
punchy, dynamic, motivating, bold
|
||||
|
||||
## Rules: Do
|
||||
- prefer semantic tokens over raw values
|
||||
- use thick (4px) borders for structural elements and containers
|
||||
- preserve visual hierarchy with bold typography and scale
|
||||
- keep interaction states explicit with scale/transform animations
|
||||
|
||||
## Rules: Don't
|
||||
- avoid thin or delicate borders
|
||||
- avoid low contrast text
|
||||
- avoid inconsistent spacing rhythm
|
||||
- avoid subtle or slow animations; prefer snappy, spring-based motion
|
||||
|
||||
## Expected Behavior
|
||||
- Follow the foundations first, then component consistency.
|
||||
- When uncertain, prioritize accessibility and clarity over novelty.
|
||||
- Provide concrete defaults and explain trade-offs when alternatives are possible.
|
||||
- Keep guidance opinionated, concise, and implementation-focused.
|
||||
|
||||
## Guideline Authoring Workflow
|
||||
1. Restate the design intent in one sentence before proposing rules.
|
||||
2. Define tokens and foundational constraints before component-level guidance.
|
||||
3. Specify component anatomy, states, variants, and interaction behavior.
|
||||
4. Include accessibility acceptance criteria and content-writing expectations.
|
||||
5. Add anti-patterns and migration notes for existing inconsistent UI.
|
||||
6. End with a QA checklist that can be executed in code review.
|
||||
|
||||
## Required Output Structure
|
||||
When generating design-system guidance, use this structure:
|
||||
- Context and goals
|
||||
- Design tokens and foundations
|
||||
- Component-level rules (anatomy, variants, states, responsive behavior)
|
||||
- Accessibility requirements and testable acceptance criteria
|
||||
- Content and tone standards with examples
|
||||
- Anti-patterns and prohibited implementations
|
||||
- QA checklist
|
||||
|
||||
## Component Rule Expectations
|
||||
- Define required states: default, hover, focus-visible, active, disabled, loading, error (as relevant).
|
||||
- Describe interaction behavior for keyboard, pointer, and touch.
|
||||
- State spacing, typography, and color-token usage explicitly.
|
||||
- Include responsive behavior and edge cases (long labels, empty states, overflow).
|
||||
|
||||
## Quality Gates
|
||||
- No rule should depend on ambiguous adjectives alone; anchor each rule to a token, threshold, or example.
|
||||
- Every accessibility statement must be testable in implementation.
|
||||
- Prefer system consistency over one-off local optimizations.
|
||||
- Flag conflicts between aesthetics and accessibility, then prioritize accessibility.
|
||||
|
||||
## Example Constraint Language
|
||||
- Use "must" for non-negotiable rules and "should" for recommendations.
|
||||
- Pair every do-rule with at least one concrete don't-example.
|
||||
- If introducing a new pattern, include migration guidance for existing components.
|
||||
|
||||
<!-- TYPEUI_SH_MANAGED_END -->
|
||||
Reference in new issue
Block a user