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,55 @@
|
||||
---
|
||||
name: Brutalism
|
||||
colors:
|
||||
primary: "#DD614C"
|
||||
secondary: "#DAA144"
|
||||
success: "#16A34A"
|
||||
warning: "#D97706"
|
||||
danger: "#DC2626"
|
||||
surface: "#FFFFFF"
|
||||
text: "#111827"
|
||||
neutral: "#FFFFFF"
|
||||
typography:
|
||||
h1:
|
||||
fontFamily: "Darker Grotesque"
|
||||
fontSize: 3rem
|
||||
body-md:
|
||||
fontFamily: "Darker Grotesque"
|
||||
fontSize: 1rem
|
||||
label-caps:
|
||||
fontFamily: "JetBrains Mono"
|
||||
fontSize: 0.75rem
|
||||
sourceScale: "desktop-first expressive scale"
|
||||
weights: "100, 200, 300, 400, 500, 600, 700, 800, 900"
|
||||
rounded:
|
||||
sm: 4px
|
||||
md: 8px
|
||||
spacing:
|
||||
sm: 4px
|
||||
md: 8px
|
||||
sourceScale: "4/8/12/16/24/32"
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
||||
Raw, anti-design aesthetic inspired by concrete architecture with unadorned elements, jarring layouts, and functional minimalism.
|
||||
|
||||
## Style Foundations
|
||||
|
||||
- **Visual style:** bold
|
||||
- **Typography scale:** desktop-first expressive scale
|
||||
- **Typography fonts:** primary=Darker Grotesque, display=Darker Grotesque, mono=JetBrains Mono
|
||||
- **Typography weights:** 100, 200, 300, 400, 500, 600, 700, 800, 900
|
||||
- **Color palette:** primary, secondary, neutral, success, warning, danger
|
||||
- **Spacing scale:** 4/8/12/16/24/32
|
||||
|
||||
## Colors
|
||||
|
||||
- **Primary (#DD614C):** Token from style foundations.
|
||||
- **Secondary (#DAA144):** Token from style foundations.
|
||||
- **Success (#16A34A):** Token from style foundations.
|
||||
- **Warning (#D97706):** Token from style foundations.
|
||||
- **Danger (#DC2626):** Token from style foundations.
|
||||
- **Surface (#FFFFFF):** Token from style foundations.
|
||||
- **Text (#111827):** Token from style foundations.
|
||||
- **Neutral (#FFFFFF):** Derived from the surface token for official format compatibility.
|
||||
@@ -0,0 +1,97 @@
|
||||
---
|
||||
name: brutalism
|
||||
description: Raw, anti-design aesthetic inspired by concrete architecture with unadorned elements, jarring layouts, and functional minimalism.
|
||||
license: MIT
|
||||
metadata:
|
||||
author: typeui.sh
|
||||
---
|
||||
|
||||
<!-- TYPEUI_SH_MANAGED_START -->
|
||||
# Brutalism Design System Skill (Universal)
|
||||
|
||||
## Mission
|
||||
|
||||
You are an expert design-system guideline author for Brutalism.
|
||||
Create practical, implementation-ready guidance that can be directly used by engineers and designers.
|
||||
|
||||
## Brand
|
||||
|
||||
a bold, "anti-design" style inspired by 1950s raw concrete architecture, prioritizing functional, unadorned, and often jarring aesthetics over polished, conventional design.
|
||||
|
||||
## Style Foundations
|
||||
|
||||
- Visual style: bold
|
||||
- Typography scale: desktop-first expressive scale | Fonts: primary=Darker Grotesque, display=Darker Grotesque, mono=JetBrains Mono | weights=100, 200, 300, 400, 500, 600, 700, 800, 900
|
||||
- Color palette: primary, secondary, neutral, success, warning, danger | Tokens: primary=#DD614C, secondary=#DAA144, success=#16A34A, warning=#D97706, danger=#DC2626, surface=#FFFFFF, text=#111827
|
||||
- Spacing scale: 4/8/12/16/24/32
|
||||
|
||||
|
||||
## Accessibility
|
||||
|
||||
WCAG 2.2 AA, keyboard-first interactions, visible focus states
|
||||
|
||||
## Writing Tone
|
||||
|
||||
concise, confident, helpful
|
||||
|
||||
## Rules: Do
|
||||
|
||||
- prefer semantic tokens over raw values
|
||||
- preserve visual hierarchy
|
||||
- keep interaction states explicit
|
||||
|
||||
## Rules: Don't
|
||||
|
||||
- avoid low contrast text
|
||||
- avoid inconsistent spacing rhythm
|
||||
- avoid ambiguous labels
|
||||
|
||||
## 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