npm - dreamcontext - Versions diffs - 0.5.0 - Mend

dreamcontext 0.5.0

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.

Files changed (247) hide show

package/dist/skill-packs/council/SKILL.md ADDED Viewed

@@ -0,0 +1,134 @@
+---
+name: council
+description: >
+  Structured multi-agent debate for non-trivial decisions. Load when the user asks to
+  "debate this", "get second opinions", "help me decide", "run this by council", or
+  invokes `/council`. Orchestrates 3–10 persona sub-agents across N rounds, then a
+  dedicated synthesizer writes a final decision report.
+tags: [council, debate, decision, sub-agents, orchestration]
+alwaysApply: false
+---
+# Council — structured multi-agent debate
+You are orchestrating a **council**: a small cast of persona sub-agents that debate
+a non-trivial decision across multiple rounds, then a dedicated synthesizer writes
+the final report. You stay **light** — you never read full sub-agent output, only
+executive summaries. Sub-agents build their own context on disk via the dreamcontext
+CLI so rounds compound without ballooning your context.
+## When to invoke
+Trigger phrases / explicit invocations:
+- `/council`
+- "debate this"
+- "get a second opinion on…"
+- "help me decide…"
+- "run this by council"
+- "council mode"
+**Use it for**: architecture choices, vendor switches, hiring decisions, product
+scope calls, incident post-mortems — anything where perspective diversity matters.
+**Do NOT use it for**: quick factual lookups, mechanical refactors, "what's the
+best variable name", or anything where the answer is knowable without debate.
+## Flow (follow this exactly)
+### 0. Scope with the user
+Ask before starting:
+1. **Rounds** — 1 (quick), 2 (default), or 3 (deep)? Recommend based on complexity.
+2. **Interrupt between rounds?** — do they want to add constraints mid-debate?
+3. **Confirm the question** — write it back verbatim.
+### 1. Create the debate
+```
+dreamcontext council create "<topic>" --rounds <N> [--interrupt]
+```
+Capture the returned `debate_id` (printed on its own last line).
+### 2. Generate personas (3–10)
+Generate personas **specific to this topic**. No preset library. Each persona should
+have:
+- A **slug** (kebab-case): `migration-risk-auditor`, `growth-cfo`, `user-advocate`
+- A **model**: `opus` for strategy/synthesis-adjacent roles; `sonnet` for most;
+  `haiku` for narrow/focused advocates. Vary them — cognitive diversity matters.
+- 2–5 **aspects** (focus areas): `[data-integrity, downtime, rollback]`
+- A **body** (100–250 words): who they are, what they obsess over, what biases they
+  bring, what would make them push back.
+For each persona:
+```
+echo "<body>" | dreamcontext council agent create <debate_id> <slug> \
+  --model <model> --aspects "<aspect1,aspect2,aspect3>"
+```
+Show the roster to the user and let them adjust before proceeding.
+### 3. Run each round
+```
+dreamcontext council round start <debate_id> <N>
+```
+For round N ≥ 2, this injects prior-round peer summaries into each persona's context
+automatically.
+**Dispatch N parallel sub-agents** (one per persona) in a single message. Use the
+`council-persona` agent type. Each dispatch prompt MUST include:
+- The debate_id and persona slug
+- The persona's model (pass via the `model` parameter)
+- Reminder: first call is `dreamcontext council round-context <id> <slug>`; last call
+  is `dreamcontext council report append <id> <slug>`.
+After all sub-agents finish:
+```
+dreamcontext council round end <debate_id> <N>
+dreamcontext council summaries <debate_id> <N>
+```
+Show summaries to the user. If `--interrupt` is set, ask for any additions to
+`## Constraints & Known Facts` in `debate.md` before starting the next round.
+### 4. Synthesize
+```
+dreamcontext council synthesize <debate_id>
+```
+This prints the manifest of files the synthesizer must read. Dispatch the
+`council-synthesizer` sub-agent (single call, model: opus) with the manifest.
+The synthesizer writes `_dream_context/council/<debate_id>/final-report.md`.
+After the synthesizer reports back:
+```
+dreamcontext council complete <debate_id>
+```
+### 5. Promote to knowledge
+Show the verdict (read just the `## Verdict` section) and final-report location to
+the user. Ask:
+> "Promote this decision to knowledge? (y / n / later)"
+- **y** → `dreamcontext council promote <debate_id>` (writes
+  `_dream_context/knowledge/decision-<slug>.md`)
+- **n / later** → leave as-is. The rem-sleep agent will pick it up during the next
+  consolidation cycle and decide based on your engagement signals.
+## Hard rules
+- **You never read full sub-agent reports.** Only `council summaries` output.
+- **Sub-agents run in parallel each round** (single message, N Agent calls).
+- **Synthesizer is a dedicated sub-agent** — not you.
+- **Persona slugs are unique per debate.**
+- **Do not skip the scope step.** If the user invoked with just "debate this",
+  still ask about rounds and interrupt.
+- **Context budget**: your per-debate total should stay under ~20K tokens. If it
+  doesn't, you are reading full reports somewhere — stop.

package/dist/skill-packs/council/debate-protocol.md ADDED Viewed

@@ -0,0 +1,90 @@
+---
+name: debate-protocol
+description: Detailed CLI protocol reference for the council skill. Load when orchestrating a debate and you need the exact command sequence and failure modes.
+tags: [council, debate, protocol, cli]
+---
+# Council debate protocol — CLI reference
+This is the exact sequence of CLI calls for the council skill, with failure modes
+and idempotency notes.
+## Commands (14 sub-commands)
+### Main-agent commands
+| Command | Purpose | Notes |
+|---|---|---|
+| `council create <topic> --rounds N [--interrupt]` | Create debate folder | Returns `debate_id` on last stdout line. Topic can span multiple args. |
+| `council agent create <id> <slug> --model <m> --aspects <a,b,c>` | Create persona | Body from `--body` or stdin. `--force` to overwrite. |
+| `council round start <id> <N>` | Start round N | Idempotent. For N≥2 injects peer summaries from round N-1 into each persona. |
+| `council round end <id> <N>` | Close round N | Fails if any persona missing. |
+| `council summaries <id> <N>` | Read exec summaries | **This is the only thing the main agent reads per round.** |
+| `council synthesize <id>` | Prepare synthesis | Prints manifest. Status → `synthesizing`. |
+| `council complete <id>` | Finalize | Requires `final-report.md` to exist. |
+| `council promote <id>` | Copy to knowledge/ | Trims to Verdict + Why + Minority views + Open risks. Skips What-was-debated + Appendix. |
+| `council list [--unpromoted\|--all]` | Triage | `--unpromoted` used by rem-sleep agent. |
+| `council show <id>` | Inspection | Prints debate metadata + round-log. |
+### Sub-agent commands
+| Command | Purpose | Notes |
+|---|---|---|
+| `council round-context <id> <slug>` | Load persona + peer cross-context | **First call every round.** |
+| `council report append <id> <slug>` | Submit round report | **Last call every round.** Body from `--body` or stdin. Validates required subsections. |
+| `council research add <id> <slug> <topic>` | Persist a research note | Body from `--body` or stdin. Soft-fail if WebFetch/WebSearch unavailable. |
+| `council research list <id> <slug>` | List prior researches | Used across rounds to avoid re-searching. |
+## Required report subsections
+`council report append` **rejects** a report missing any of:
+- `### Executive Summary` (≤150 words recommended — soft-warn if longer)
+- `### Position`
+- `### Reasoning`
+- `### Reactions to peers`
+- `### Open questions`
+## Failure modes and recovery
+- **Sub-agent submits report without Executive Summary** → `report append` exits
+  non-zero. Re-dispatch the sub-agent with a corrected prompt.
+- **`round end` fails with "missing reports from…"** → one or more sub-agents didn't
+  finish. Re-dispatch only the missing ones.
+- **`round start` called twice on same round** → idempotent; no-op if cross-context
+  already injected.
+- **User cancels mid-round** → state is recoverable; `debate.md` frontmatter stores
+  `current_round` and `status`. Resume with `round start` (same N) or `round end`.
+- **Research tools unavailable** → sub-agent proceeds without researches/; not an
+  error.
+- **`promote` refuses** because status ≠ `complete` → call `council complete` first
+  (requires `final-report.md` to exist).
+## File layout (on disk, after a 2-round 3-persona debate)
+```
+_dream_context/council/
+├── index.json
+└── council_xYz123/
+    ├── debate.md              # frontmatter + Question + Constraints & Known Facts
+    ├── round-log.md           # append-only timeline
+    ├── final-report.md        # written by synthesizer
+    ├── migration-risk-auditor/
+    │   ├── context-and-persona.md   # persona body + per-round cross-context
+    │   ├── report.md                # round entries LIFO
+    │   └── researches/              # optional
+    │       ├── index.json
+    │       └── firestore-rollback-patterns.md
+    ├── dx-champion/
+    └── user-advocate/
+```
+## Context-budget discipline
+The orchestrator (main agent) should only read:
+- `council create` output (debate_id)
+- `council summaries <id> <N>` output (one per round)
+- `council synthesize <id>` output (manifest)
+- The `## Verdict` section of `final-report.md` (read via a single Read tool call,
+  section only — not the whole file)
+If the orchestrator reads full `report.md` files, the design is being violated.

package/dist/skill-packs/design/SKILL.md ADDED Viewed

@@ -0,0 +1,301 @@
+---
+description: "Universal design system — 4px grid spacing, typography scales, HSL/OKLCH colors, visual hierarchy, Gestalt laws, depth system, layout patterns, WCAG accessibility, emotional design (interaction quality hierarchy), mascot workflow. Sub-skills: frontend-principles (zero hardcoded values, token architecture, i18n, a11y), design-web (responsive, landing pages, conversion science), design-mobile (haptics, native transitions, widgets, App Store screenshots, gamification), onboarding-design (paywalls, signup funnels, questionnaire UX)."
+alwaysApply: true
+ruleType: "Design System"
+version: "1.3"
+---
+## Sub-Skills (Read Before Specific Work)
+| When you are about to... | Read first |
+|--------------------------|------------|
+| Build any frontend UI — components, tokens, translations, responsive layout, i18n, a11y | `frontend-principles.md` |
+| Design websites, landing pages, responsive layouts, web animations, conversion optimization | `design-web.md` |
+| Design mobile apps (iOS/Android), haptics, native transitions, widgets, App Store screenshots | `design-mobile.md` |
+| Design onboarding flows, paywalls, signup funnels, first-run UX, rating prompts | `onboarding-design.md` |
+---
+<system_instructions>
+<role>
+You are the **Creative Director & UI Architect**. You define the visual system — the WHAT of design.
+**This skill is MANDATORY for all frontend work.** Every agent writing UI code MUST load `design-principles` to understand the design system before implementation.
+**Authority**: These standards override personal preferences. Design must be intentional, system-based, and mathematically consistent.
+**Scope**: Visual hierarchy, spacing systems, typography scales, color palettes, depth, layout structure, creative process.
+</role>
+<compliance_rules>
+1. **4px Grid is Law**: All spacing/sizing MUST be divisible by 4.
+2. **HSL/OKLCH Only**: No Hex/RGB for system colors.
+3. **No Text Walls**: Break content with layout structure.
+4. **Accessibility First**: Contrast ratios and hit targets must meet WCAG AA.
+5. **System Before Code**: Define tokens (spacing, type, colors) BEFORE writing any CSS/styles.
+</compliance_rules>
+---
+## I. Core Design Philosophy
+### 1. Minimalist Imperative
+**"Good design is as little design as possible."**
+- **Essentialism**: Focus on the core interaction (Input + Button) before the wrapper (Header + Footer).
+- **Cognitive Load**: Users scan; they don't read. Simplify visual inputs.
+- **The 80/20 Rule**: Typography is 90% of design. Layout is the rest. Decoration is <1%.
+### 2. Gestalt Laws
+| Law | Principle | Application |
+|---|---|---|
+| **Proximity** | Objects close together = related | Use spacing to group inputs with labels. |
+| **Similarity** | Same style = same function | All primary buttons must look identical. |
+| **Closure** | Brain fills gaps | Use whitespace instead of borders to separate sections. |
+### 3. Visual Hierarchy
+**Tools of Emphasis** (in order of power):
+1. **Size**: Larger = more important (but don't overdo it).
+2. **Weight**: Bold > Regular.
+3. **Color**: High Contrast (Black/White) > Low Contrast (Gray).
+4. **Spacing**: Isolated elements draw attention.
+5. **Depth**: Raised elements (Shadows) > Flat elements.
+**The "Squint Test"**: If you squint, the primary action and H1 must be the only things visible.
+### 4. Iconography Consistency
+**Rule**: Never mix lined (outline) and filled icon styles in the same UI. Pick one style and use it system-wide.
+| Convention | Rule |
+|---|---|
+| **Single style** | All icons in a view use the same weight/fill. No mixing icon sets. |
+| **Tab bar exception** | Lined icons for unselected state, filled for selected state — the only acceptable mixing pattern. |
+| **Sizing** | Icons follow the 4px grid: 16px, 20px, 24px, 32px. No odd sizes. |
+| **Consistency > novelty** | Swapping default AI-suggested icons to a single consistent set = immediate quality boost. |
+**Icon Resources**: Hero Icons (free, first choice) → Font Awesome → Nucleio (premium).
+---
+## II. The Spacing System (4px Grid)
+**Standard**: All spatial values (margins, padding, sizing, line-height) must be divisible by **4**.
+### The Scale (REM-based)
+| Token | REM | Pixels | Usage |
+|---|---|---|---|
+| `--space-1` | `0.25rem` | 4px | Icon optical adjustment |
+| `--space-2` | `0.5rem` | 8px | Tight grouping (Label + Input) |
+| `--space-3` | `0.75rem` | 12px | Compact separation |
+| `--space-4` | `1rem` | 16px | **Base Unit** / Component padding |
+| `--space-5` | `1.25rem` | 20px | Navigation items |
+| `--space-6` | `1.5rem` | 24px | Card padding |
+| `--space-8` | `2rem` | 32px | Section separation (Internal) |
+| `--space-12` | `3rem` | 48px | Section separation (External) |
+| `--space-20` | `5rem` | 80px | Hero / Footer padding |
+### Spacing Rules
+- **Vertical Rhythm**: Rows need breathing room (50px-80px padding).
+- **Start Big**: Always start with *too much* whitespace, then reduce.
+- **Line Height**: Acts as natural bottom margin. Don't add `margin-bottom` to text unless it exceeds the line-height gap.
+---
+## III. Typography System
+**Strategy**: Limit choices to maximize consistency. You only need **3 sizes** for 90% of the UI.
+### The Minimal Scale
+1. **Base (Body)**: 16px (`1rem`). The workhorse.
+2. **Heading (Title)**: 20px-24px (`1.25rem`-`1.5rem`). Section headers.
+3. **Small (Meta)**: 13px-14px (`0.875rem`). Captions, hints.
+*(Display sizes of 32px+ are reserved for H1 Hero only)*
+### Hierarchy via Weight & Color
+Don't rely on size alone. Use **HSL Lightness** for hierarchy:
+| Role | Weight | Lightness (Light Mode) | Lightness (Dark Mode) |
+|---|---|---|---|
+| **Primary** | 600 (Semi) | 0-10% (Black) | 90-100% (White) |
+| **Secondary** | 400 (Reg) | 40% (Dark Gray) | 60% (Light Gray) |
+| **Tertiary** | 400 (Reg) | 60% (Gray) | 40% (Dim Gray) |
+### Line Height Logic
+- **Inverse Proportionality**: Smaller text = larger line-height.
+  - Body (16px) → 1.5 - 1.6
+  - Headings (24px+) → 1.1 - 1.2
+- **Optical Spacing**: Line-height creates "phantom" padding. Account for it.
+---
+## IV. Color System (HSL / OKLCH)
+**Imperative**: Use **HSL** or **OKLCH**. Never use Hex for system colors.
+### The Palette Structure
+- **Neutrals** (Saturation 0%): The UI skeleton.
+  - **Base**: Background (L=100% Light / L=0% Dark).
+  - **Surface**: Cards/Panels (L=96% Light / L=5% Dark).
+  - **Border**: Dividers (L=90% Light / L=15% Dark).
+- **Primary** (Brand): Action color. Used on <10% of UI (Buttons, Links).
+- **Semantic**: Signal colors (Success/Green, Error/Red, Warning/Yellow).
+### Dark/Light Conversion
+**Physics Rule**: Light comes from the top.
+- **Light Mode**: "Raised" elements are *lighter* (closer to light source).
+- **Dark Mode**: "Raised" elements are *lighter* (closer to light source).
+- **Algorithm**: `Light_L = 100 - Dark_L` (baseline, then optically adjust).
+### Depth System
+Depth = **Layers** + **Shadows** + **Highlights**.
+- **Layers**: 3 levels of background lightness (Base < Surface < Elevated).
+- **Shadows**:
+  - `sm`: `0 1px 2px` (Buttons)
+  - `md`: `0 4px 6px` (Cards)
+  - `xl`: `0 20px 25px` (Modals)
+  - *Pro Tip*: Use colored shadows (primary hue, 15% opacity) for richness.
+- **Highlight**: 1px top border (white/lighter) mimics light hitting the edge.
+---
+## V. Layout Fundamentals
+### Row-Based Architecture
+- **Rule of Isolation**: One idea per row.
+- **Visual Separation**: Alternate row backgrounds (White → Gray → White) to delineate sections.
+- **Container**: Max-width (e.g., `1200px`) centers content; background spans full width.
+### Standard Patterns
+- **Hero**: H1 + Subtext + CTA + Visual.
+- **Bento Grid**: Asymmetric boxes for features.
+- **Split Screen**: 50/50 Image/Text (Alternate L/R).
+- **Card Grid**: Repeated items (Testimonials, Features).
+### Content-First Workflow
+1. **Draft**: Write the content (headings, bullets).
+2. **Structure**: Choose the layout pattern that fits the content density.
+3. **Style**: Apply typography and spacing systems.
+4. **Decorate**: Add shadows, gradients, and icons **last**.
+---
+## VI. Accessibility Standards
+- **Contrast**: WCAG AA minimum — 4.5:1 for body text, 3:1 for large text and UI components.
+- **Hit targets**: Minimum 44x44px for touch, 24x24px for pointer.
+- **Motion**: Respect `prefers-reduced-motion`. Provide alternatives.
+- **Color alone**: Never convey information by color alone (use icons/labels too).
+---
+## VII. The Creative Process (The Remix Strategy)
+**Core Principle**: Everything is a Remix. Originality is overrated; execution is everything.
+### The Remix Workflow
+1. **Inspiration**: Never start from a blank canvas. Source from the Design Inspiration Resources table below. Find 3 proven patterns. Real products > Dribbble concepts.
+2. **Deconstruction**: Analyze *why* it works. "Why is this button here?" "Why this spacing?"
+3. **Transformation**: Combine + improve. Apply your 4px grid and type system. Make it cleaner, faster, more accessible. Adapt for your user persona.
+4. **Assembly**: Define `spacing`, `type-scale`, `colors` tokens BEFORE building. Construct using *only* system tokens.
+5. **Refinement**: Squint Test → Consistency Check (all margins ÷ 4?) → Add subtle character (gradients, noise, organic shapes).
+### Mascot & Custom Illustration Workflow
+Mascots create emotional connection and give apps personality. They turn empty states, onboarding, and error pages from dead screens into character moments.
+1. **Commission base art**: Hire an illustrator ($200-300) for the initial character. This creates a unique reference that AI cannot replicate from text prompts alone.
+2. **Mash references**: Feed 2+ visual references into AI image generation. Single reference = derivative; multiple references = original synthesis.
+3. **AI iteration**: Use ChatGPT with commissioned art as reference. One ask at a time yields better results than complex multi-instruction prompts. ChatGPT > Gemini for initial character creation; Gemini better for iterations on established base.
+4. **Animation**: Use Midjourney (feed static mascot as starting frame) to create animated variants for splash screens, login, onboarding.
+5. **Placement rule**: Mascots appear at emotional touchpoints (onboarding, empty states, error recovery, celebration moments) — not on every screen.
+### App Naming Strategy
+- **Check domain availability early**: Don't fall in love with a name you can't own online.
+- **Avoid unusual spelling**: Clever misspellings create confusion and hurt discoverability.
+- **Short name + descriptive suffix**: e.g., ellieplanner.com, lunabudgeting.com. The suffix helps with SEO and user understanding.
+- **Treat early names as placeholders**: Rebrand without guilt once the product has traction. Don't over-invest in naming pre-launch (~2 hours max).
+### Design Inspiration Resources
+| Resource | Focus | Notes |
+|---|---|---|
+| **Mobbin** | Real app screenshots & flows | Primary resource. Paid. Browse to build design taste. |
+| **60fps.design** | Interaction & animation references | Discover novel micro-interactions from top apps. |
+| **Spotted & Prod** | Top app animations curated | Same concept as 60fps — curated animation inspiration. |
+| **Screenshot First Company** | App Store screenshot design | Twitter/X account. Before/after ASO screenshot examples. |
+| **Figma Community** | Component libraries, templates | Free starting points and pattern references. |
+### Originality vs. Usability
+| Concept | Rule |
+|---|---|
+| **Jakob's Law** | Users spend most time on *other* sites. They expect yours to work the same way. |
+| **Innovation Tokens** | Spend innovation on the *product value*, not the navigation bar. |
+| **Trend Cycles** | Trends are circular. Don't chase trends; build timeless systems. |
+---
+## VIII. Emotional Design System
+**Core Principle**: Design triggers emotional responses, not just functional outcomes. Interaction quality determines whether a product feels cheap, competent, or premium. (Reference: Don Norman's *Emotional Design*)
+### 1. Interaction Quality Hierarchy
+Every UI element exists on a 5-level scale. Target **Level 3 minimum**; Level 4+ for primary flows.
+| Level | Name | Definition | Example |
+|---|---|---|---|
+| 1 | **Functional** | It works. No feedback beyond state change. | Button submits form, nothing else happens. |
+| 2 | **Smooth** | Transitions and timing feel natural. No jank. | 200ms ease-out on state changes. |
+| 3 | **Delightful** | Interaction produces a small positive emotion. | Success checkmark animates in with a bounce. |
+| 4 | **Memorable** | User remembers and talks about the experience. | Celebration confetti on first milestone. |
+| 5 | **Premium** | Polish signals quality of the entire product. | Every micro-interaction compounds into brand perception. |
+### 2. Emotional Feedback Loop Rules
+- **Feedback must be emotional, not just functional**: A toggle that snaps with a micro-animation > a toggle that just changes state. The response IS the reward.
+- **Progress must be visible and celebrated**: Never let the user achieve something silently. Acknowledge every milestone: progress bars, streak counters, completion animations.
+- **Success states are designed, not default**: Empty success (plain text "Done") is a missed opportunity. Design success states with the same care as error states.
+- **Polish is not decoration — it is trust**: In high-stakes domains (finance, health, security), micro-interaction quality directly signals product reliability. Users equate visual polish with backend competence.
+### 3. Interaction State Design (Mandatory)
+Every interactive element MUST define all 5 states. No state may be left to browser defaults.
+| State | Purpose | Design Rule |
+|---|---|---|
+| **Default** | Resting appearance | Must clearly signal interactivity (cursor, affordance). |
+| **Hover** | Discovery / anticipation | Subtle lift or color shift. Change within 100ms. |
+| **Focus** | Keyboard navigation / a11y | Visible ring (2px+). Never remove `outline` without replacement. |
+| **Active/Pressed** | Confirmation of action | Slight scale-down (0.97-0.98) or darken. Feels tactile. |
+| **Disabled** | Unavailable | Reduced opacity (0.5) + `cursor: not-allowed`. Never just gray text. |
+### 4. Domain-Specific Emotional Models
+Select the emotional model that matches the product domain:
+| Model | Domain | Emotional Strategy | Reference |
+|---|---|---|---|
+| **Habit Loop** | Education, fitness, social | Celebrate small wins, streaks, mascot expressions. Make repetition rewarding. | Duolingo |
+| **Trust Signal** | Finance, security, health | Polish = safety. Smooth feedback during risky actions. Approachable language for complex concepts. | Phantom |
+| **Premium Perception** | Fintech, SaaS, luxury | Micro-interactions compound into quality perception. Tactile data viz. Onboarding signals positioning. | Revolut |
+---
+## IX. Design Checklist
+- [ ] **Sourced**: Found 3 real-world examples (not concepts)?
+- [ ] **Systematized**: Tokens defined before implementation?
+- [ ] **Spacing**: All values rem-based and divisible by 4?
+- [ ] **Typography**: Using only the 3-size scale (+ Hero display)?
+- [ ] **Colors**: HSL/OKLCH only? Semantic names? No hex in components?
+- [ ] **Hierarchy**: Passes Squint Test?
+- [ ] **Accessibility**: WCAG AA contrast? Touch targets ≥ 44px?
+- [ ] **Consistency**: Same patterns used for same functions everywhere?
+- [ ] **Iconography**: Single icon style used consistently? Active/inactive states use weight shift (thin→filled)?
+- [ ] **Interaction States**: All interactive elements define Default/Hover/Focus/Active/Disabled?
+- [ ] **Emotional Feedback**: Primary actions have Level 3+ feedback (not just functional state change)?
+- [ ] **Design tie-breaker**: Stuck between two options? Use a public poll (Twitter/X) to break the tie with real user input.
+- [ ] **Success States**: Success/completion moments are designed, not just plain text?
+</system_instructions>