@hcu-lab.me/mcp-device 1.0.9 → 1.0.12

package/control-plane/scripts/skills/executing-plans/scripts/task-done

@@ -0,0 +1,52 @@
+#!/usr/bin/env bash
+# Close one task of an inline plan execution in a single call: run the task's
+# test command, keep its full output in the workspace, print the tail, and —
+# only if the command succeeded — append the completion line to the ledger.
+# A failing command records nothing: the task is not complete.
+#
+# Usage: task-done PLAN_FILE TASK_NUMBER BASE -- TEST_COMMAND [ARGS...]
+#   BASE is the SHA task-start printed; the completion line records BASE..HEAD.
+# Exit: the test command's exit status.
+set -euo pipefail
+
+if [ $# -lt 5 ] || [ "$4" != "--" ]; then
+  echo "usage: task-done PLAN_FILE TASK_NUMBER BASE -- TEST_COMMAND [ARGS...]" >&2
+  exit 2
+fi
+
+plan=$1
+n=$2
+base=$3
+shift 4
+sdd="$(cd "$(dirname "$0")/../../subagent-driven-development/scripts" && pwd)"
+
+git rev-parse --verify --quiet "$base" >/dev/null || { echo "bad BASE: $base" >&2; exit 2; }
+
+dir=$("$sdd/sdd-workspace" "$plan")
+log="$dir/task-${n}-tests.log"
+ledger="$dir/progress.md"
+
+# Render the command the way a person would type it, for the ledger line.
+cmd=""
+for a in "$@"; do
+  case "$a" in
+    *[[:space:]\"\;\|\&]*) cmd="$cmd '$a'" ;;
+    *) cmd="$cmd $a" ;;
+  esac
+done
+cmd=${cmd# }
+
+rc=0
+"$@" > "$log" 2>&1 || rc=$?
+
+tail -n 5 "$log"
+if [ "$rc" -ne 0 ]; then
+  echo "task-done: test command exited $rc; Task $n NOT recorded (full output: $log)" >&2
+  exit "$rc"
+fi
+
+last=$(grep -v '^[[:space:]]*$' "$log" | tail -n 1)
+[ -f "$ledger" ] || printf '# SDD ledger — plan: %s\n' "$plan" > "$ledger"
+line="Task $n: complete (commits $(git rev-parse --short=7 "$base")..$(git rev-parse --short=7 HEAD), tests: $cmd → $last)"
+printf '%s\n' "$line" >> "$ledger"
+echo "ledger: $line"

package/control-plane/scripts/skills/executing-plans/scripts/task-start

@@ -0,0 +1,28 @@
+#!/usr/bin/env bash
+# Begin one task of an inline plan execution in a single call: extract the
+# task's brief (via subagent-driven-development's task-brief, so both skills
+# share one workspace) and record BASE, the commit the task's review range is
+# cut from. One tool call instead of two, because every call in an inline
+# session is a turn that re-reads the whole context.
+#
+# Usage: task-start PLAN_FILE TASK_NUMBER
+# Prints:
+#   brief: <path to the task's brief file>
+#   base:  <full SHA of HEAD>
+set -euo pipefail
+
+if [ $# -ne 2 ]; then
+  echo "usage: task-start PLAN_FILE TASK_NUMBER" >&2
+  exit 2
+fi
+
+plan=$1
+n=$2
+sdd="$(cd "$(dirname "$0")/../../subagent-driven-development/scripts" && pwd)"
+
+out=$("$sdd/task-brief" "$plan" "$n")
+brief=$(printf '%s\n' "$out" | sed -n 's/^wrote \(.*\): [0-9][0-9]* lines$/\1/p')
+[ -n "$brief" ] || { echo "task-brief did not report a path: $out" >&2; exit 1; }
+
+echo "brief: $brief"
+echo "base: $(git rev-parse HEAD)"

package/control-plane/scripts/skills/extract-design-md/SKILL.md

@@ -0,0 +1,358 @@
+---
+name: extract-design-md
+description: >-
+  Use when analyzing an existing frontend source tree to extract design tokens, component conventions, and visual language into DESIGN.md without rendering or redesigning the interface.
+allowed-tools:
+  - "stitch*:*"
+  - "Bash"
+  - "Read"
+  - "Write"
+  - "web_fetch"
+---
+
+# Extract Design System from Frontend Code
+
+Analyze frontend source code to extract a comprehensive design system document
+(DESIGN.md) that captures the project's visual language — colors, typography,
+spacing, component patterns, and layout principles — directly from the source
+files, without needing to build or render the application.
+
+## Why This Exists
+
+The `design-md` skill works from rendered HTML. But often you have a codebase
+and want to understand its design system before you can even run the app —
+maybe dependencies are missing, the build is broken, or you just want a quick
+audit. This skill reads the source files themselves: stylesheets, component
+files, theme configs, and Tailwind setups. It's faster and works anywhere.
+
+## When to Use
+
+- User has a frontend codebase and wants to extract or document its design system
+- User wants to migrate a project's visual identity into Stitch
+- User asks to "audit the styling" or "understand the design language" of a repo
+- User wants to create a DESIGN.md from existing source code
+- The app can't be built/rendered but the source is available
+- User wants to unify or reconcile inconsistent styles across a codebase
+
+## Prerequisites
+
+- Access to the frontend project's source directory
+- No build or runtime dependencies needed — this skill reads source files only
+
+---
+
+## Workflow
+
+### Phase 1: Project Discovery
+
+Start by understanding what you're working with. This determines which
+extraction patterns to use.
+
+#### 1. Detect the Framework and Stack
+
+Scan the project root for telltale files:
+
+| Signal File | Framework / Tool |
+|:---|:---|
+| `package.json` with `react` | React / Next.js |
+| `package.json` with `vue` | Vue / Nuxt |
+| `package.json` with `svelte` | Svelte / SvelteKit |
+| `package.json` with `@angular/core` | Angular |
+| `tailwind.config.js/ts` | Tailwind CSS |
+| `postcss.config.js` | PostCSS pipeline |
+| `styled-components` or `@emotion` in deps | CSS-in-JS |
+| `.css` / `.scss` / `.less` files only | Plain CSS / SASS |
+| `theme.js` / `theme.ts` / `tokens.js` | Design token files |
+
+Read `package.json` first — it reveals the framework, CSS tooling, and any
+design-token libraries (e.g., `style-dictionary`, `@chakra-ui/react`,
+`@mui/material`, `ant-design`). This context tells you *where* to look for
+styling information.
+
+#### 2. Map the Source Tree
+
+Identify the key directories and files you'll analyze:
+
+```
+src/
+├── components/     ← Component-level styles
+├── styles/         ← Global stylesheets
+├── theme/          ← Theme definitions, tokens
+├── assets/         ← Fonts, images
+├── app.css         ← Root styles
+└── index.css       ← Entry CSS
+```
+
+Also check for:
+- `tailwind.config.js` / `tailwind.config.ts` — Custom colors, fonts, spacing
+- `globals.css` / `global.css` — CSS custom properties (variables)
+- Any `theme.*` or `tokens.*` files
+- Component library config (e.g., `chakra-theme.ts`, `vuetify.config.ts`)
+
+#### 3. Read Framework-Specific Guidance
+
+Consult the appropriate reference for extraction patterns:
+
+- **React / Next.js / Tailwind** → [references/react-tailwind.md](references/react-tailwind.md)
+- **Vue / Nuxt** → [references/vue.md](references/vue.md)
+- **Svelte / SvelteKit** → [references/svelte.md](references/svelte.md)
+- **Angular** → [references/angular.md](references/angular.md)
+- **Plain CSS / SASS / Less** → [references/plain-css.md](references/plain-css.md)
+
+These references contain framework-specific patterns for locating colors,
+typography, spacing, and component styles. Read the one that matches before
+proceeding.
+
+---
+
+### Phase 2: Deep Extraction
+
+Work through each design dimension systematically. For each one, gather raw
+data from the source files, then synthesize it into descriptive language.
+
+The goal isn't to dump every CSS property — it's to understand the *intent*
+behind the styling choices and describe them in human, editorial language that
+another designer (or Stitch) can use to recreate the same visual feel.
+
+#### 1. Visual Theme & Atmosphere
+
+Read the broadest styling first to understand the overall mood:
+
+- **Root background**: What's the `body` or root element background? Light
+  cream (#f-range) signals airy/clean; dark (#0-#2 range) signals moody/dramatic.
+- **Whitespace philosophy**: Are spacing values generous (32px+) or tight?
+  Check padding/margin values on root containers, section wrappers, and card components.
+- **Density**: Count the components per page/section. Few with space = minimal;
+  many packed tight = information-dense.
+- **Color temperature**: Are the neutrals warm (creams, tans) or cool (blue-grays, slates)?
+- **Overall feel**: Synthesize into 1-2 rich sentences that capture the mood.
+
+Look for these signals in the source:
+
+| Source Location | What It Tells You |
+|:---|:---|
+| Root `background-color` or Tailwind `bg-*` on layouts | Overall lightness/darkness |
+| Spacing scale in Tailwind config or CSS vars | Whitespace philosophy |
+| Number of components vs. wrapper padding | Density |
+| Custom property naming (`--warm-*` vs `--cool-*`) | Color temperature intent |
+| Comments in theme files | Design intent in the developer's own words |
+
+#### 2. Color Palette & Roles
+
+Extract every unique color from the codebase and assign functional roles.
+Search across all layers:
+
+**Where to find colors:**
+
+| Layer | What to Search |
+|:---|:---|
+| CSS custom properties | `--color-*`, `--primary`, `--bg-*` |
+| Tailwind config | `theme.extend.colors` |
+| Theme/token files | Color objects, palettes |
+| Component styles | `background-color`, `color`, `border-color` |
+| Inline/scoped styles | `bg-*`, `text-*` classes in templates |
+| CSS-in-JS theme objects | `colors`, `palette` keys |
+
+**How to organize:** Group colors by function, not by hue:
+
+1. **Primary Foundation** — Background and surface colors
+2. **Accent & Interactive** — CTA buttons, active states, links
+3. **Typography & Text Hierarchy** — Primary, secondary, tertiary text
+4. **Functional States** — Success, error, warning, info
+
+For each color, create a descriptive name that evokes the color's character
+rather than its raw hex value:
+
+- ❌ `#294056` → "Blue"
+- ✅ `#294056` → **"Deep Muted Teal-Navy"** — Primary CTA, active navigation
+
+**Deduplication matters.** Codebases often have near-duplicate colors (e.g.,
+`#333` and `#2C2C2C`). Consolidate them under one name that best represents
+the intended color.
+
+#### 3. Typography Rules
+
+Extract the complete typographic system:
+
+**Font families:**
+- Check CSS `font-family`, Tailwind `fontFamily`, Google Fonts links, or
+  local `@font-face` declarations.
+- Note the **character** of each font: geometric vs humanist, serif vs sans,
+  the feeling it evokes.
+
+**Type scale (hierarchy):**
+- Find every heading level (H1-H6) and body text, noting:
+  - `font-size` (in rem or px)
+  - `font-weight` (numeric value + descriptive name)
+  - `letter-spacing` (and why — elegance? compactness?)
+  - `line-height` (generous for readability? tight for display?)
+- Map component usage: Which heading level do product cards use? What about
+  hero sections?
+
+**Spacing principles:**
+- How does text spacing relate to the overall spacing scale?
+- Letter-spacing patterns on headings vs body
+- Line-height philosophy (generous/relaxed for body, tighter for display)
+
+#### 4. Component Stylings
+
+Analyze the 4-5 most important UI primitives:
+
+**Buttons:**
+- Corner radius (and what it communicates — playful? professional? minimal?)
+- Color scheme for primary, secondary, and ghost variants
+- Hover/focus/active states and transition timing
+- Padding ratios (horizontal vs vertical)
+
+**Cards / Containers:**
+- Corner radius (often different from buttons — slightly rounder)
+- Shadow strategy: flat, subtle hover shadows, or always elevated?
+- Border treatment: hairline borders, colored accents, or none?
+- Internal padding (generous or compact?)
+- Image treatment within cards (full-bleed, padded, rounded?)
+
+**Navigation:**
+- Layout pattern (horizontal bar, vertical sidebar, drawer)
+- Typography treatment (uppercase, letter-spacing, weight)
+- Active/hover state indicators (underline, color, background)
+- Mobile behavior (hamburger, bottom nav, drawer)
+
+**Inputs & Forms:**
+- Border style and focus state behavior
+- Corner style consistency with buttons
+- Padding and touch-target sizing
+
+**Domain-Specific Components:**
+- Identify 1-2 components unique to this project (e.g., product cards,
+  dashboard widgets, chat bubbles) and describe their styling patterns.
+
+#### 5. Layout Principles
+
+Extract the structural system:
+
+**Grid & Structure:**
+- Max content width (from `max-width` on containers)
+- Column system (CSS Grid, Flexbox patterns, defined breakpoints)
+- Responsive breakpoints (from media queries or Tailwind config)
+
+**Whitespace Strategy:**
+- Base spacing unit (8px grid? 4px? custom?)
+- Section margins (how much space between major sections)
+- Edge padding (page margins at different breakpoints)
+
+**Alignment & Visual Balance:**
+- Text alignment patterns (centered heroes, left-aligned body)
+- Image-to-text ratios
+- Visual weight distribution
+
+**Responsive Behavior:**
+- Mobile-first or desktop-first?
+- How do grids collapse? Padding scale?
+- Touch target sizing
+
+#### 6. Stitch Generation Notes
+
+Synthesize the extraction into actionable prompts for Stitch:
+
+- **Atmosphere language**: Translate the mood into natural descriptors
+- **Color references**: List colors by descriptive name + hex
+- **Component prompts**: Write 2-3 example prompts that would recreate
+  key components in Stitch
+- **Iteration guidance**: Tips for refining screens in this design system
+
+---
+
+### Phase 3: Write the DESIGN.md
+
+Assemble everything into the standard DESIGN.md format. Place it at
+`.stitch/DESIGN.md` in the project directory (create the `.stitch/` directory
+if it doesn't exist).
+
+> [!IMPORTANT]
+> You **MUST** include the YAML frontmatter at the top of the file with `name` and `colors` mapping, exactly as shown in the example at [examples/DESIGN.md](examples/DESIGN.md). This structured data is required for other skills to parse the design system.
+>
+> Failure to include this YAML block with at least the core color tokens is a failure to use this skill correctly.
+
+Use the format from the example at [examples/DESIGN.md](examples/DESIGN.md) as your template. The file must start with the YAML block, followed by the markdown sections:
+
+```markdown
+# Design System: [Project Name]
+**Project ID:** [If known, otherwise omit]
+
+## 1. Visual Theme & Atmosphere
+[Rich 2-paragraph description of mood, philosophy, and key characteristics]
+
+## 2. Color Palette & Roles
+### Primary Foundation
+### Accent & Interactive
+### Typography & Text Hierarchy
+### Functional States
+
+## 3. Typography Rules
+### Hierarchy & Weights
+### Spacing Principles
+
+## 4. Component Stylings
+### Buttons
+### Cards & [Domain-Specific Containers]
+### Navigation
+### Inputs & Forms
+### [Domain-Specific Components]
+
+## 5. Layout Principles
+### Grid & Structure
+### Whitespace Strategy
+### Alignment & Visual Balance
+### Responsive Behavior & Touch
+
+## 6. Design System Notes for Stitch Generation
+### Language to Use
+### Color References
+### Component Prompts
+### Incremental Iteration
+```
+
+---
+
+### Phase 4: Integration (Optional)
+
+If the user wants to push the design system into Stitch:
+
+1. Hand off to the `manage-design-system` skill for the MCP create/update calls
+2. The DESIGN.md you wrote is the input — the manage-design-system skill handles
+   the Stitch API integration
+
+If the user just wants the document, you're done after Phase 3.
+
+---
+
+## Quality Checklist
+
+Before delivering the DESIGN.md, verify:
+
+- [ ] Every color has a descriptive name, hex code, and functional role
+- [ ] Typography includes font family, character description, and full hierarchy
+- [ ] Component styles describe shape, color, states, and transitions
+- [ ] Layout includes max-width, grid, breakpoints, and spacing strategy
+- [ ] Stitch generation notes use natural language, not CSS syntax
+- [ ] The atmosphere section reads like editorial copy, not technical docs
+- [ ] Near-duplicate colors are consolidated
+- [ ] The document captures the *intent* behind styling, not just raw values
+
+## Tips for Better Extraction
+
+- **Read comments and commit messages.** Developers often document design
+  intent in code comments (`/* hero section — breathable */`) and commit
+  messages. These are gold for understanding the *why*.
+- **Check for design-token libraries.** If the project uses `style-dictionary`,
+  `@tokens-studio`, or similar, these files are the most authoritative
+  source of design values.
+- **Theme files are higher-signal than component styles.** A `theme.ts` that
+  defines a palette tells you the intended design system; scattered inline
+  styles in components tell you what actually shipped. Both matter, but
+  start from the theme.
+- **Tailwind config is a design system.** If a project has a customized
+  `tailwind.config.js`, that *is* the design system — extract from it first,
+  then spot-check components for overrides.
+- **CSS custom properties are intentional.** If a developer defined
+  `--brand-primary`, they're telling you this is a design token. Respect that.

package/control-plane/scripts/skills/extract-design-md/examples/DESIGN.md

@@ -0,0 +1,210 @@
+---
+name: Alpine Peak
+colors:
+  surface: '#fcf8fa'
+  surface-dim: '#dcd9db'
+  surface-bright: '#fcf8fa'
+  surface-container-lowest: '#ffffff'
+  surface-container-low: '#f6f3f5'
+  surface-container: '#f0edef'
+  surface-container-high: '#eae7e9'
+  surface-container-highest: '#e4e2e4'
+  on-surface: '#1b1b1d'
+  on-surface-variant: '#45464d'
+  inverse-surface: '#303032'
+  inverse-on-surface: '#f3f0f2'
+  outline: '#76777d'
+  outline-variant: '#c6c6cd'
+  surface-tint: '#565e74'
+  primary: '#000000'
+  on-primary: '#ffffff'
+  primary-container: '#131b2e'
+  on-primary-container: '#7c839b'
+  inverse-primary: '#bec6e0'
+  secondary: '#5c5f61'
+  on-secondary: '#ffffff'
+  secondary-container: '#e0e3e5'
+  on-secondary-container: '#626567'
+  tertiary: '#000000'
+  on-tertiary: '#ffffff'
+  tertiary-container: '#161c22'
+  on-tertiary-container: '#7e848c'
+  error: '#ba1a1a'
+  on-error: '#ffffff'
+  error-container: '#ffdad6'
+  on-error-container: '#93000a'
+  primary-fixed: '#dae2fd'
+  primary-fixed-dim: '#bec6e0'
+  on-primary-fixed: '#131b2e'
+  on-primary-fixed-variant: '#3f465c'
+  secondary-fixed: '#e0e3e5'
+  secondary-fixed-dim: '#c4c7c9'
+  on-secondary-fixed: '#191c1e'
+  on-secondary-fixed-variant: '#444749'
+  tertiary-fixed: '#dde3eb'
+  tertiary-fixed-dim: '#c1c7cf'
+  on-tertiary-fixed: '#161c22'
+  on-tertiary-fixed-variant: '#41474e'
+  background: '#fcf8fa'
+  on-background: '#1b1b1d'
+  surface-variant: '#e4e2e4'
+typography:
+  display-lg:
+    fontFamily: Inter
+    fontSize: 48px
+    fontWeight: '800'
+    lineHeight: 56px
+    letterSpacing: -0.02em
+  headline-md:
+    fontFamily: Inter
+    fontSize: 24px
+    fontWeight: '700'
+    lineHeight: 32px
+    letterSpacing: -0.01em
+  body-base:
+    fontFamily: Inter
+    fontSize: 16px
+    fontWeight: '400'
+    lineHeight: 24px
+    letterSpacing: '0'
+  body-bold:
+    fontFamily: Inter
+    fontSize: 16px
+    fontWeight: '600'
+    lineHeight: 24px
+    letterSpacing: '0'
+  label-caps:
+    fontFamily: Lexend
+    fontSize: 12px
+    fontWeight: '700'
+    lineHeight: 16px
+    letterSpacing: 0.05em
+  stat-lg:
+    fontFamily: Lexend
+    fontSize: 32px
+    fontWeight: '600'
+    lineHeight: 40px
+    letterSpacing: -0.02em
+rounded:
+  sm: 0.25rem
+  DEFAULT: 0.5rem
+  md: 0.75rem
+  lg: 1rem
+  xl: 1.5rem
+  full: 9999px
+spacing:
+  unit: 4px
+  xs: 4px
+  sm: 8px
+  md: 16px
+  lg: 24px
+  xl: 32px
+  gutter: 16px
+  margin-mobile: 20px
+  margin-desktop: 40px
+---
+
+## Brand & Style
+
+The brand personality is high-performance, sophisticated, and dependable. It is
+designed for the modern skier who demands clarity and precision in harsh
+environments. The visual language evokes the crystalline beauty of a mountain
+peak while prioritizing the rugged utility required for outdoor navigation.
+
+The design system utilizes **Glassmorphism** to achieve a "frozen" aesthetic,
+mimicking the properties of ice and packed snow. This is paired with a
+**High-Contrast** philosophy to ensure that critical data—like trail status and
+weather alerts—remains legible under intense mountain sunlight or the
+low-visibility conditions of a snowstorm.
+
+## Colors
+
+The palette is anchored by **Deep Peak Blue**, a dark navy that provides a
+grounding contrast for white text and maps. **Powder White** serves as the
+primary canvas, ensuring the interface feels airy and cold.
+
+**Safety Orange** is reserved strictly for primary calls to action, hazard
+warnings, and emergency trail closures, ensuring immediate eye-tracking.
+**Electric Blue** (the info status) is used for weather updates and general
+interactivity. For trail difficulty levels, standard industry colors (Green,
+Blue, Black) are used but rendered with high-saturation values to pop against
+the white backgrounds.
+
+## Typography
+
+The typography system uses **Inter** for core functional text and body copy due
+to its exceptional x-height and legibility at small sizes. **Lexend** is
+introduced for labels and statistics; its hyper-readable, athletic character
+suits the "active" nature of skiing data like speed and vertical drop.
+
+To combat outdoor glare, font weights are generally heavier than standard web
+applications. Display styles use tight tracking and heavy weights to create a
+sense of strength. Labels always utilize high-contrast coloring against their
+backgrounds.
+
+## Layout & Spacing
+
+This design system uses a **Fluid Grid** model with generous safe areas.
+Elements are spaced using a strict 4px/8px baseline rhythm to maintain a
+disciplined, professional appearance.
+
+Touch targets are intentionally oversized (minimum 48x48px) to accommodate users
+wearing gloves. Padding within cards and containers is kept spacious (`lg` or
+`xl`) to prevent the interface from feeling cluttered when displaying complex
+trail data.
+
+## Elevation & Depth
+
+Depth is conveyed through **Glassmorphism** and backdrop filters rather than
+traditional heavy shadows. Surfaces use a hierarchy of transparency:
+
+1.  **Base Layer:** Solid 'Powder White' or 'Deep Peak Blue'.
+2.  **Middle Layer (Cards/Modals):** 70% opacity white with a 20px backdrop blur
+    and a thin 1px 'Ice' border (white at 40% opacity).
+3.  **Top Layer (Floating Actions):** 90% opacity with a subtle 4px ambient
+    shadow to separate the element from the blurred background.
+
+This creates a "stacked ice" effect that maintains visual clarity while giving
+the UI a premium, modern feel.
+
+## Shapes
+
+The shape language is defined by modern, organic **rounded corners**. This
+softens the high-contrast color palette and makes the app feel approachable.
+
+Interactive elements like buttons and chips utilize `rounded-lg` (1rem) or
+`rounded-xl` (1.5rem) to suggest a tactile, "pebble" feel. Large containers like
+map overlays use 1rem corners, while small status indicators for trail
+difficulty may use pill shapes for instant recognition.
+
+## Components
+
+### Buttons
+
+Primary buttons use a solid 'Safety Orange' or 'Deep Peak Blue' fill with white
+text. High-contrast outlines are used for secondary actions. All buttons must
+feature a minimum height of 52px for gloved-hand accessibility.
+
+### Cards & Modals
+
+Cards utilize the glassmorphism effect—semi-transparent backgrounds with a 1px
+white border. This ensures that map imagery or photos underneath remain slightly
+visible, maintaining the "frozen" aesthetic.
+
+### Trail Status Chips
+
+Pill-shaped indicators with high-saturation icons. Green (Easy), Blue
+(Intermediate), Black (Expert), and Double Black (Extreme). These must include
+text labels alongside icons to ensure accessibility for colorblind users.
+
+### Input Fields
+
+Fields feature a 'Cloud Gray' background with a thick bottom border that
+transforms into 'Electric Blue' on focus. Labels are always visible above the
+field to ensure the user doesn't lose context in bright environments.
+
+### Weather Widgets
+
+Bold, thick-stroke iconography (minimum 2pt stroke) to represent sun, snow, or
+wind. These icons should be large and accompanied by 'Lexend' typography for
+temperature and wind speed.